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5.6  ENGAGEMENTS  MODULE 

The  Engagements  Module  contains  the  logic  which  governs  the 
positioning  of  opposing  ground  units  during  confrontations.  This  module 
functions  in  conjunction  with  the  Ground  Movement  Module  to  direct  units 
toward  the  center  of  greatest  enemy  threat.  Specifically,  during  the 
course  of  unit  movement,  this  module  determines  whether  an  engagement  can 
be  initiated  as  a result  of  enemy  contact.  Once  an  engagement  has  been 
formed,  this  module  maintains  the  engagement  by  mobilizing  opposing  units 
against  one  another.  Furthermore,  the  eventual  withdrawal  by  the  unit 
from  the  engagement  is  handled  by  this  module.  This  withdrawal  will 
ultimately  cause  the  unit  to  change  its  state  of  operation  and  its  manner 
of  movement.  Finally,  the  Engagements  Module  coordinates  with  the  Ground 
Fire  Module  by  determining  whether  a unit  will  be  allowed  to  discharge 
direct-fire  weapons  against  its  enemy. 

The  Engagements  Module  is  described  in  a detailed,  subroutine-by- 
subroutine  level  in  the  CATTS  Trainer  Programming  Report,  pages  5-371 
through  5-412.  Each  subroutine  is  also  described  in  detail  in  the  MAFIA  V 
Programmer's  Manual.  Very  few  changes,  other  than  increases  in  table 
sizes,  have  been  made  to  this  module  throughout  the  CATTS  development 
period,  and  these  two  earlier  documents  still  provide  accurate  information 
for  the  interested  reader.  This  User's  Manual  will  therefore  discuss  the 
Engagements  Module  from  a higher-level,  overall  point  of  view  rather  than 
an  individual  subroutine  point  of  view,  in  order  to  avoid  unnecessary 
duplication  of  previous  documentation  as  well  as  provide  the  overview  of 
the  module  which  has  heretofore  been  missing.  Figure  5-93  shows  the 
module  subroutine  linkage,  and  Table  5-45  gives  a brief  description  of 
each  subroutine  along  with  principal  inputs  and  outputs. 

5.6.1  Overview 

The  Engagements  Module  along  with  the  Ground  Movement  Module  controls 
the  movement  of  all  units  involved  in  engagements.  During  the  simulation, 
a ground  unit  is  moved  in  discrete  segments  toward  its  desired 
destination.  Each  movement  step  is  followed  by  a check  to  determine 
whether  the  unit  has  come  close  enough  to  initiate  an  engagement  with  the 
enemy.  If  an  engagement  can  be  established,  the  unit  is  instructed  to  move 

__ - ' 


TaDle  b-45.  Engagements  Submodule  Subroutine  Descriptions 


IXPMIB(K)  - Position  of  blue  FEBA  center 

in  direction  of  engagement 


Table  5-45.  Engagements  Submodule  Subroutine  Descriptions  (Continued) 

Subroutine  Description  Principal  Inputs/ Outputs 


Page  5-615 


X 

<u 

L- 

S- 

• X) 

»— 

to  1 

«* 

■ . 

< -*-> 

o 

o 

CD 

i-  CD  03 

S- 

r— 

•f-  QJ 

to 

■ — - 

LU  CD 

■O 

*- 

CL 

i 

O C -r- 

o 

ID 

3 

X CD  X3  •- 

CVJ 

OC  tO 

O 

CD  <D 

*4—  •»—  L- 

«4- 

to  * 

«4— 

CD 

03  03 

CD 

4-> 

4-> 

L.  r— 

CL  03 

c 

C 

CD  4->  4-> 

xc 

O 

c 

CL 

XL 

L-  -Q 

r—  3 > 

c o 

4-> 

03 

•r— 

4-J  C 

03  03 

a; 

CD 

+-> 

3 03 

O 

o •*- 

•r— 

to 

C QJ 

r—  x: 

CO 

^ 4-> 

E 

O 

1 

o T 

QJ  L U 

QJ 

4-> 

c 

U. 

o 

QJ 

3 4 -» 

<x 

-O  C 

a/ 

X 

s_ 

3 CD 

3 

4->  03 

3 

O 

o 

E -c 

u 

CO 

CD 

CD 

CD 

03 

«—  C 

r— 

U C 

<4- 

0J  ■*-> 

F—  • 

LU 

X)  E 

03 

‘4- 

. > 

03  i — 3 

03 

<D  03 

<4- 

X3 

CD  1 

03  X3 

u_ 

CD  OJ 

CD 

m. 

O 

CD 

> 03 

> 

tO 

o 

c 

03  x: 

O QJ 

' — < 

C CD 

C 

CO 

c -*-» 

C O 

CL 

03 

CD 

i- 

•*-  fO 

CD 

CD 

•r—  **"— 

03  O D 

03 

CD  X 

QJ 

LO 

C i- 

to 

• 

‘a-  CD 

□I 

X3 

CL  C 

+->  -r- 

4-J 

QJ  QJ 

X3 

— ' 

QJ  O 

>s  O 

^ — - 

0/  c 

*4- 

Cl.  . 

O 

3 3 

03  4->  tO 

03 

1/3 

O 

c 

c 

r— 

»4- 

03  4-> 

r— 

-o  a; 

•r— 

X CO 

U 

O 

X)  03  X) 

•a 

r— 

U 

o 

o 

5 

• 

4-> 

— • CD 

l-  O 

S-  C 

T— 

•r— 

•r— 

II 

o c 

CD 

x: 

tO  -C 

CD 

tO 

U 

4-> 

CD  ■*“* 

4->  CD  O 

4-> 

• 3 

4-> 

4-> 

4-> 

o 

<£  3 

■ — 

ft?  4-> 

CD 

to  L- 

C 

c a a 

c 

3)  *4— 

c 

u 

03 

►— « 

CO 

CD 

X 

03  O 

CD 

tO 

• 

QJ  O tO  • 

03 

QJ 

0J 

C 

ou  4-> 

-Q 

<c 

CD 

CD 

*4- 

E 

03  "O 

Q 

E QJ  r~ 

E 

03 

E 

to 

03 

u 

CO 

to 

CD 

(D 

CD 

c c 

C_> 

QJ  X S-  h- 

QJ 

4-> 

QJ 

CD 

II  QJ 

4->  E 

E 

LU 

s_ 

CD 

E "O 

> 

O O 

t— 

> -*->  L_  Q 

> 

•r-  L- 

> 

aj 

CL 

C 

L- 

c o 

O 

u. 

X o 

CD 

o 

03  CD 

O 

CL  > 

O 1 O > 

O 

c o 

O 

QJ 

X 

•r— 

*— < -r— 

QJ  L- 

S- 

•—* 

03  *4- 

1 

c 

CO  V- 

4->  CO 

21 

nuj: 

2: 

3 *4- 

2: 

t/3 

QJ 

to 

' — X3 

E V- 

*4- 

— ' 

O 

o 

Q 


1 — 
Q 

Z 


<£ 

LU 

CH 

Q 


( I FEBAR ( K , 1 ) , I F EBAR ( K , 2 ) ) 


Table  5-45.  Engagements  Submodule  Suoroutine  Descriptions  (Continued) 

Subroutine  Description  Principal  Inputs/Outputs 


Output:  IXf’HIB  - See  ADJDIR.  Set  to  -7999999 
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Table  b-45.  Engagements  Submodule  Subroutine  Descriptions  (Continued) 
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Table  S-45.  Engagements  Submodule  Subroutine  Descriptions  (Continued) 

Subroutine  Description  Principal  Inputs/ Outputs 


MVTCD  - See  subroutine  ADJDIR. 


normal 

engaged,  eligible  to  fin 
direct  fire  against 
enemy  units  in  engage- 
ment. 


Table  b-45.  Engagements  Submodule  Subroutine  Descriptions  (Continued) 


coordinate  (L  * 2)  of  opera- 
tional grouping  J. 


Table  5-45.  Engagements  Submodule  Subroutine  Descriptions  (Continued) 

Description  Principal  Ini 
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F = location  (midpoint)  of  friendly  FEBA  - ( IFEBAB(K,1 ) , IFEBAB(K,2)) 
E = location  (midpoint)  of  enemy  FEBA  = ( IFEBAR(K,1 ) , IFEBAR(K,2)) 


f = engagement  axis 


= direction  of  engagement  axis  from 

blue  FEBA  midpoint  to  red  FEBA  = ( D I REAX ( K , 1 ) , DIREAX(K,2)) 
midpoint 

K = engagement  number 


Figure  5-94.  FEBA  Definition 
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c = center  location  of  friendly  FEBA  (IFEBAB) 

d = half-frontage  of  friendly  force  (IBFRNT) 

r = range  from  endpoint;  also  depth  of  scope  area  (NGARNG) 

t = engagement  axis  defined  by  (sin  e,  cose)  (DIREAX) 


Figure  5-95.  Scope  of  the  Engagement 
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P = center  of  opposing  FEBA  for  engagement  K 

= (IFEBAB(K.l),  IFEBAB(K,2)),  if  unit  I is  red 
= (IFEBAR(K.l),  IFEBAR(K,2) ) , if  unit  is  blue 

= opposing  half-frontage  of  engagement  K 

= IBFRNT(K),  if  unit  I is  red 
= IRFRNT(K),  if  unit  I is  blue 

$2  ~ maximum  distance  beyond  end  of  opposing  FEBA  that  a unit 
of  the  same  type  and  side  as  unit  I may  join  the  exist- 
ing engagement.  If  I is  in  an  op  group,  then  the  type 
of  its  op  group  is  used. 

= ITYPDW(KT,1 ) , if  unit  I is  red 
= ITYPDW(KT,2) , if  unit  I is  blue 

Where  KT  = ITYPEU(I)  if  I does  not  belong  to  an  op  group, 
and  KT  = I0GTYP( IN0G( I ) ) if  it  does. 

Figure  5-97.  NGARGN  Calculates  Whether  a Unit  Lies 
Within  the  Scope  of  an  Engagement 
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directly  toward  the  nearest  enemy  unit.  Upon  arrival  at  the  enemy's 
location,  the  unit  is  instructed  to  form  a new  engagement  if  the  (closest) 
enemy  unit  is  not  already  engaged,  or  to  join  the  engagement  if  the  enemy 
unit  is  involved  iri  a confrontation.  In  either  case,  the  parameters 
governing  unit  movement  and  operational  status  are  changed  so  that 
engagement  maneuvers  can  be  performed.  Note  that  engagement  initiation 
is  triggered  by  the  arrival  of  two  opposing  units;  this  is  handled  by 
the  Ground  Movement  Module. 

The  creation  of  an  engagement  entails  the  definition  of  several 
attr'*'"tes . These  attributes  the  formation  and  the  relative 

positions  taken  by  each  unit  involved  in  the  engagement.  In  all,  an 
engagement  is  comprised  of  six  attributes.  These  are: 

1)  The  direction  of  the  engagement  axis,  DIREAX,  calculated 
by  ADJDIR  with  a call  to  ENGDIR. 

2)  The  half-frontage  of  the  blue  and  red  forces,  IBFRNT  and 
IRFRNT , calculated  by  FRNTGS . 

3)  The  X,Y  coordinates  of  the  center  point  of  the  blue  and 
red  forward  edges  of  the  battle  area  (FEBAs),  IFEBAB  and 
IFEBAR,  calculated  by  FWDLIN. 

4)  The  positions  of  the  forwardmost  operational  grouping  or 

unit  for  each  side  is  expressed  in  a rotated  coordinate  system 
in  which  the  positive  X-axis  is  in  the  direction  of  the 
engagement  axis;  the  resulting  positions  determine  the  center 
points  of  each  FEBA.  Calculated  by  FWDLIN,  and  stored  in 
IXPHIB  and  IXPHIR. 

5)  The  controlling  operational  groupings  for  each  side,  if  they 
exist,  NCBOG  and  NCROG,  calculated  by  FWDLIN. 

6)  The  area  of  close  support  for  both  blue  and  red  forces,  to 
be  used  to  direct  opposing  artillery  fire.  Calculated  by 
ADJDIR  using  input  IEfJDPl  and  IENDP2. 

An  engagement  is  uniquely  defined  by  the  numerical  values  assigned 
to  each  attribute.  Engagement  attributes  (i.e.,  the  numerical  valu • 
assigned  to  them)  change  during  the  simulation  accordin'!  to  battle 
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conditions;  this  necessitates  that  the  attributes  be  updated  every 
time-step  during  the  simulation. 

5 . 6 . 1 . 1 Es tabl ishing  the  Forward  Edge  of  the  Battle  Area  (FEBA) 

The  forward  edge  of  the  battle  area  (FEBA)  is  the  single  most 
important  concept  used  by  the  CATTS  math  model  to  simulate  an  engagement. 
When  two  opposing  forces  are  in  confrontation,  two  parallel  reference 
lines,  called  FEBAs , are  used  by  the  movement  and  firing  logic  to  perform 
engagement  decisions  and  operations  which  simulate  the  battle. 

Specifically,  units  are  deployed,  or  moved  to  certain  deployment  positions 
where  they  can  utilize  direct-fire  weapons  against  one  another. 

Each  FEBA  has  a definite  location,  orientation,  and  length  associated 
with  it.  Figure  5-94  depicts  the  FEBAs  for  two  opposing  units.  A FEBA  is 
established  by  a point  called  the  center  location,  and  a frontage  length. 

The  center  location  is  determined  by  the  location  of  the  controlling  (i.e., 
forwardmost)  operational  grouping,  if  it  exists.  If  there  is  no  controlling 
operational  grouping,  then  the  unit  belonging  to  the  engagement  which  is 
nearest  to  the  enemy  force  has  its  location  taken  as  the  center  location 
of  the  FEBA.  The  word  "forwardmost"  and  the  phrase  "nearest  to  the  enemy 
force"  are  synonymous.  This  determination  is  made  by  examining  unit 
locations  in  a rotated  coordinate  system  having  the  positive  X-axis  coincide 
with  the  direction  of  the  engagement  axis.  When  the  center  location  for 
each  side  has  been  established,  the  vector  drawn  from  the  blue  center  to 
the  red  center  redefines  the  engagement  axis.  Note  that  by  convention, 
the  orientation  of  the  engagement  axis  is  always  taken  to  be  a directed 
segment  originating  at  the  blue  center  and  terminating  at  the  red  center. 
Thus,  the  direction  of  the  engagement  axis  is  uniquely  specified.  Once 
the  axis  vector  has  been  constructed,  a pair  of  parallel  line  segments, 
one  passing  through  each  center  location,  perpendicular  to  the  engagement 
axis,  form  the  frontages  for  the  respective  sides  participating  in  the 
engagement.  The  length  of  the  frontage  is  equal  to  twice  the  half-frontage 
for  the  respective  forces.  The  half-frontage  is  either  half  the  unit  width 
if  only  a single  unit  is  involved,  or  in  the  case  where  an  operational 
grouping  is  involved,  the  lateral  distance  determined  by  the  unit  of  the 
group  having  the  largest  perpendicular  distance  from  the  engagement  axis 
plus  half  of  that  unit's  width.  Five  of  the  first  six  attributes  listed 
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above  are  used  to  determine  i.ne  FERA.  This  gives  an  indication  of  the 
relative  importance  of  the  FEBA  concept  in  the  simulation  of  engagements. 

5. 6. 1.2  Ground  Fire  During  Engagements 

Engagements  affect  the  use  of  support  and  direct  fire  armaments. 

For  automatic  support-fire  allocation,  an  engagement  has  close  support 
and  interdictory  regions  defined.  These  regions  are  rectangular  areas 
whose  sides  are  determined  by  1)  the  larger  of  the  two  engagement 
frontages,  and  2)  a given  depth  measured  either  from  the  friendly  FEBA 
or  enemy  FEBA,  depending  upon  the  value  of  the  fire  support  weapon  code. 

Any  opposing  unit  within  the  close  support  region  is  fired  at  from  mode  3 

or  4,  the  close  support  modes.  Any  opposing  unit  within  the  interdictory 
region  is  fired  at  from  mode  5.  A more  detailed  explanation  of  support- 
fire  weapons  is  given  in  Section  5.4. 

Engagements  allow  units  to  utilize  their  direct-fire  armaments.  To 
be  eligible  to  do  such,  the  engaged  unit  must  satisfy  certain  criteria. 

The  main  requirement  involves  the  distance  between  the  unit  and  the 
enemy  FEBA  (see  equation  8).  This  distance  must  not  exceed  the  unit's 
pre-determined  engagement  range.  Other  unit  considerations,  such  as 
maneuver  control  status,  location  relative  to  the  controlling  operational 

grouping  if  one  exists,  etc.,  are  examined  before  eligibility  to  discharge 

direct-fire  weapons  can  be  established.  These  details  are  discussed 
in  subsequent  sections.  In  general,  an  engagement  will  involve  opposing 
forces  focusing  their  attentions  primarily  toward  one  another,  especially 
to  utilize  their  direct-fire  weapons  against  one  another.  Two  opposing 
units,  however,  are  not  prohibited  from  firing  at  each  other  when  either 
or  both  are  unengaged.  Likewise,  two  opposing  units  in  different 
engagements  are  not  prohibited  from  firing  at  each  other. 

5.6.2  Operation 

The  determination  as  to  when  an  engagement  is  to  be  started  is  made 
by  the  Ground  Movement  Module.  Recal 1 that  during  each  time-step,  a new 
location  is  scheduled  for  a unit  based  upon  the  unit's  current  location, 
direction  of  movement,  and  speed.  However,  before  the  move  is  conducted, 
a check  is  made  to  ensure  that  the  unit  will  neither  encounter  an  obstacle 
obstruction  nor  confront  an  enemy  unit.  Both  occurrences  will  prevent  the 
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unit  from  achieving  its  scheduled  move.  In  the  latter  instance,  several 
criteria  are  evaluated  to  determine  whether  a new  engagement  can  be 
initiated.  The  most  important  criterion  involves  the  distance  to  the 
nearest  enemy  unit.  If  the  several  criteria  are  satisfied,  the  unit  is 
instructed  to  move  toward  the  enemy  unit  (movement  code  14).  A new 
destination  (i.e.,  the  location  of  the  enemy  unit)  is  specified,  thus 
modifying  the  direction  of  movement  for  the  unit.  This,  in  turn,  causes 
a revised  location  to  be  scheduled  for  the  unit.  But  before  the 
revision  takes  place,  the  unit's  previous  movement  code  and  movement 
data  are  saved.  This  allows  the  unit's  previous  movement  status  to  be 
reinstated  in  the  event  that  an  engagement  is  not  formed,  or  upon 
eventual  termination  of  the  engagement.  The  changing  of  unit  movement 
code  to  14  in  order  to  pursue  an  enemy  unit  as  a result  satisfying 
certain  criteria  signifies  the  first  step  of  engagement  initiation. 

All  unengaged  moving  units  are  inspected,  first  red,  then  blue  to 
determine  if  the  moves  scheduled  during  the  current  time-step  will  satisfy 
certain  criteria  necessary  to  form  engagements  with  enemy  units.  Units 
of  the  red  army,  designated  first  as  the  weapon  units,  are  moved  against 
target  units  of  the  blue  army;  then  their  respective  roles  are  interchanged. 
A given  weapon  unit  is  evaluated  along  with  each  and  every  target  unit. 

The  target  unit  must  be  a nondefunct  ground  unit.  The  weapon  unit  is  also 
required  to  be  a nondefunct  ground  unit.  It  must  be  moving  in  an 
unengaged  condition  (i.e.,  movement  codes  5,  6,  8,  9,  10,  11,  12,  13,  14, 
or  15).  With  respect  to  obstacles,  it  must  not  be  in  the  process  of 
traversing  through  an  obstacle.  The  first  duty  of  a unit  caught  within 
an  obstacle  is  to  clear  the  obstacle;  then  it  is  permitted  to  pursue  an 
enemy  unit. 

5.6. 2.1  Engagement  Criteria  Between  Weapon  and  Target  Units 

The  most  important  criteria  governing  the  formation  of  a new  engagement 
are:  1)  visual  detection  of  the  target  unit  by  the  weapon  unit,  and 

2)  the  distance  separating  the  two  units.  Before  an  engagement  can  be 
initiated,  visual  contact  by  the  weapon  unit  must  have  been  established 
with  the  target  unit.  If  no  such  detection  is  made,  the  weapon  unit  will 
immediately  ignore  the  target  unit  and  proceed  to  consider  the  next 
target  unit.  Engagement  initiation  cannot  occur  with  unseen  target  units. 
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The  detection  decision  is  based  upon  the  values  in  table  IFIREFA,  as 
stored  by  subroutine  DETECT  (see  Section  5.3.1). 

However,  once  detection  is  made,  the  distance  between  the  opposing 
units  is  determined.  The  weapon  unit  has  a characteristic  data  input 
engagement  range  NGARNG,  determined  by  unit  type  and  side,  that  specifies 
the  distance  at  which  it  may  initiate  an  engagement  with  an  enemy  unit. 

It  also  has  another  characteristic  range,  also  pre-defined  by  data  input 
MFIGHT,  according  to  unit  type,  which  specifies  the  range  at  which  it  must 
initiate  an  engagement  with  an  enemy  unit.  This  more  restrictive  range  is 
called  the  must-fight  range;  any  target  located  within  the  weapon  unit's 
j must-fight  range  will  be  automatically  considered  for  engagement.  This 

consideration  is  made  regardless  of  the  intents  and  maneuver  control 
statuses  of  the  units  involved.  In  other  words,  the  target  unit  is  so 
near  the  weapon  unit  (perhaps  50  meters),  that  a new  engagement 
must  be  started.  This  will  happen  unless  the  weapon  unit  enco1  ers  yet 
another  target  unit  that  is  even  closer  during  subsequent  pr  ing. 

Three  cases  exist  with  respect  to  a given  weapon  unit's  gement 

and  must-fight  ranges.  They  are  as  follows: 

1)  Target  units  may  be  located  beyond  the  weapon  unit's 
engagement  range. 

2)  Target  units  may  be  located  within  the  weapon  unit's 
engagement  range  but  beyond  its  must-fight  range. 

3)  Target  units  may  be  located  within  the  weapon  unit's 
must-fight  range. 

The  first  case  is  handled  easily.  Target  units  located  beyond  the 
weapon  unit's  engagement  range  are  ignored.  No  action  is  initiated;  the 
weapon  unit  immediately  proceeds  to  consider  the  next  target  unit. 

The  second  case  requires  a detailed  examination  of  several  unit 
attributes.  Target  units  which  are  within  the  weapon  unit's  engagement 
range,  but  beyond  the  must-fight  range  may  or  may  not  be  eligible  to 
originate  an  engagement.  The  verdict  depends  upon  certain  attributes: 

1)  Whether  the  unit  is  a member  of  an  operational  grouping 

2)  Intent  of  the  unit  (1  = avoid  engagement,  2=  engage  as 
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necessary,  3 = seek  engagement) 


3)  Whether  the  unit  is  engaged  or  unengaged 

An  engagement  may  be  started  if  the  weapon  and  tarqet  units  have 
attributes  which  coincide  with  one  of  the  sets  of  attributes  described 
in  Table  5-46.  The  logic  involved  in  determining  eligibility  to  initiate 
engagement  is  illustrated  in  Figure  5-98.  The  numeral  atop  each  decision 
box  traces  out  the  logic  path  corresponding  to  the  set  of  attributes 
detailed  in  Table  5-46. 

Among  all  eligible  target  units,  the  one  that  is  nearest  the  weapon 
unit  is  chosen  to  participate  in  forming  the  new  engagement.  The  weapon 
unit  will  have  its  movement  code  changed  to  14  (moving  to  a point 
relative  to  an  enemy  unit)  so  that  its  objective  is  now  to  pursue  the 
nearest  target  unit.  Note  that  before  the  change  takes  place,  the  weapon 
unit's  old  movement  code  and  movement  data  are  saved.  This  precaution  is 
taken  in  the  event  that  engagement  initiation  is  aborted. 

The  weapon  unit  will  travel  under  movement  code  14  until  it  arrives 
at  a point  where  it  will  confront  the  enemy  unit.  At  this  point,  both 
weapon  and  target  units  are  released  from  maneuver  control  if  either 
were  under  such  control.  This  will  allow  the  built-in  movement  logic  to 
set  up  the  values  to  be  assigned  for  each  engagement  attribute.  If  the 
enemy  is  already  involved  in  an  engagement,  a new  engagement  is  not 
started.  Instead,  the  weapon  unit  will  join  the  existing  engagement.  If 
the  weapon  unit  is  a member  of  an  operational  grouping,  the  other  members 
of  the  grouping  are  made  to  deploy  into  pre-determined  positions  relative 
to  the  weapon  unit.  They  too  will  join  the  engagement. 

If  the  enemy  unit  is  unengaged,  a new  engagement  is  started.  The 
following  actions  are  taken  to  assign  values  to  attributes  which  uniquely 
define  the  engagement: 

1)  Determine  red  and  blue  FEBAs  (IFEBAB,  IFEBAR,  IXPHIB,  IXPHIR). 

2)  Compute  engagement  axis  vector  from  blue  FEBA  center  to  red 
FEBA  center  (DIREAX). 

3)  Deploy  units  relative  to  operational  grouping  in  groupin  . . which 
are  moving  toward  an  engagement  intending  to  deplov  on  arrival. 
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Figure  5-98.  Logic  Determining  Eligibility  of  Engagement  Initiation 
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4)  Determine  which  side  controls  the  engagement  (NCB0G,  NCR0T). 

5)  Calculate  engagement  frontage  IBFRNT,  IRFRNT  of  controlling 
side  from  either  operational  grouping  deployment  or  unit  width. 

6)  Calculate  engagement  frontage  of  opposing  side  by  expanding 

or  contracting  the  opposing  side's  normal  frontage,  if  applicable, 
or  simply  calculate  normal  frontages  from  operational  grouping 
deployment  or  unit  width. 

7)  Deploy  units  in  controlling  operational  groupings  on  both 
sides  of  the  engagement. 

56.2.2  Updating  and  Maintaining  Engagements 

All  values  describing  the  entities  which  comprise  an  engagement  are 
updated  once  per  time-step.  The  updates  are  accomplished  in  four  distinct 
steps.  The  first  step  deals  with  one-sided  engagements.  The  axes  of 
single-sided  engagements  are  re-defined  each  time-step;  units  and  operational 
groupings  involved  in  such  engagements  are  re-deployed  to  correspond  to  the 
new  axes • The  second  step  recomputes  the  location  of  each  nondefunct 
operational  grouping  and  determines  the  unit  within  each  operational 
grouping  which  is  farthest  forward  in  the  direction  of  attack.  The  third 
step  examines  each  engagement  to  update  the  following: 

1)  FEBA  locations  for  the  red  and  blue  forces  involved  (IFEBAR, 

IFEBAB). 

2)  The  new  red  and  blue  controlling  operational  groups  if  they 
exist  for  the  engagement  (NCROG,  NCBOG). 

3)  The  distance  of  each  unit  involved  in  the  engagement  from  its 
respective  enemy  FEBA  (IXPHIR,  IXPHIB). 

Finally,  the  fourth  step  recalculates  the  half-width  of  each 
engagement  frontage  (IBFRNT,  IRFRNT). 

5 . 6 . 2 . 2 . 1 Updating  One-sided  Engagements 

The  engagement  axis  of  a one-sided  engagement  is  updated  each  time- 
step.  The  prime  objective  is  to  keep  the  attacking  force  aimed  toward 
the  center  of  greatest  immediate  enemy  threat.  A radius  of  responsibility 
about  the  attacking  force’s  FEBA  center  is  established.  This  radius  is 
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determined  by  the  distance  between  the  centers  of  the  red  and  blue  FEBA's 
plus  the  close  support  region  width  for  the  attacking  force.  The  center 
of  greatest  immediate  threat  is  taken  to  be  the  center  of  mass  of  all 
opposing  units  having  the  following  properties: 

1)  The  opposing  unit  is  not  part  of  this  engagement,  or  is  unengaged. 

2)  The  distance  from  the  unit  to  the  attacking  force's  FEBA  center 
is  less  than  the  radius  of  responsibility. 

3)  The  opposing  unit  is  in  front  of  the  attacking  force's  FEBA. 

These  properties  will  encompass  possible  enemy  target  units  which  are 
located  within  a semi-circular  area  about  the  attacking  force's  FEBA 
center.  This  is  illustrated  by  Figure  5-99.  The  direction  of  the 
engagement  axis  is  established  by  drawing  the  vector  between  the  center 
of  mass  and  the  attacking  force's  FEBA  center  (the  orientation  of  the 
vector,  of  course,  muse  be  from  blue  to  red,  regardless  of  the  color  of 
the  respective  forces). 

Once  the  direction  of  the  engagement  axis  has  been  updated,  all 
member  units  of  the  attacking  force  have  their  directions  of  movement 
made  to  point  at  the  enemy's  center  of  mass.  If  the  attacking  units  make 
up  operational  groupings,  then  these  operational  groupings  have  their 
directions  of  movement  similarly  modified.  Furthermore,  if  any  of  those 
operational  groupings  are  deployed,  each  unit  in  the  operational  groupings 
is  redeployed  according  to  the  new  engagement  axis  direction.  The 
direction  of  a one-sided  engagement  axis  is  recomputed  each  time-step  to 
guide  the  attacking  force  toward  the  area  of  greatest  enemy  threat. 

5. 6. 2. 2. 2 Updating  Locations  of  Operational  Groupings 

The  locations  of  all  nondefunct  operational  groupings  are  recomputed 
each  time-step.  This  must  be  done  because  during  engagements,  units 
within  operational  groupings  are  moving  toward  their  deployment  positions. 

In  addition,  the  forwardmost  unit  (i.e.,  closest  to  the  enemy)  in  an 
operational  grouping  may  change  during  the  simulation  according  to  battle 
conditions. 

The  update  procedure  begins  by  determining  the  location  of  the  most 
advanced  unit  in  the  operational  grouping.  To  achieve  this,  the  coordinates 
of  each  member  unit  in  the  operational  grouping  are  transformed  to  a 
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F = center  of  friendly  FEBA  (IFEBAB) 

E = center  of  enemy  FEBA  (IFEBAR) 
d = depth  of  close  support  region  (IENDP1  or  IENDP2) 

| = engagement  axis  (DIREAX) 

Figure  5-99.  Area  of  Responsibility  to  Determine  Greatest 
Immediate  Threat  in  One-sided  Engagements 
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rotated  coordinate  system  whose  positive  x-direction  coincides  with  the 
direction  of  movement  of  the  operational  grouping.  This  transformation  is 
represented  by  the  matrix  in  equation  3.  The  forwardmost  unit  is 
determined  by  examining  the  transformed  x-coordinate  of  each  unit  in  the 
operational  grouping.  The  unit  having  the  largest  x-coordinate  value  is 
the  unit  which  is  most  advanced.  Identifying  the  forwardmost  unit  is 
important  because  the  positioning,  movement,  and  conduct  of  the  non-lead 
units  of  the  group  are  affected  by  the  actions  of  the  lead  unit.  For 
instance,  deployment  positions  are  made  with  respect  to  the  forwardmost 
unit.  Another  example  involves  movement  speed;  members  of  an  operational 
grouping  cannot  be  moving  faster  than  the  forwardmost  unit. 

The  location  of  an  operational  grouping  is  determined  by  one  of  two 
methods,  depending  upon  its  movement  code.  First  of  all,  operational 
groupings  having  movement  codes  4 or  16  need  not  have  their  locations 
updated  since  their  member  units  are  all  deployed  and  waiting  for  other 

t 

forces  to  deploy.  These  operational  groupings  retain  their  previous 
location.  Operational  groupings  having  movement  codes  5 through  14  have 
their  locations  determined  by  the  locations  of  their  forwardmost  units. 
Finally,  operational  groupings  which  are  engaged  and  moving  (movement 
codes  1 , 2 or  3)  or  not  engaged  but  in  the  process  of  deploying  (movement 
code  15),  have  their  locations  computed  in  the  rotated  system.  Specifically, 
the  transformed  x-coordinate  of  the  forwardmost  unit,  and  the  mean 
transformed  y-coordinate  of  the  units  in  the  grouping  determine  the  new 
location  (in  the  rotated  system)  of  the  operational  grouping.  The  coordinates 
of  the  new  location  are  transformed  back  into  the  original  Cartesian  system 
(see  equation  9) . 

5. 6. 2. 2. 3 Updating  FEBA  Centers 

The  center  location  of  each  side's  FEBA  is  recomputed  every  time-step. 
Also  the  controlling  operational  grouping,  if  they  exist,  for  each  side 
is  determined.  Furthermore,  the  distance  from  the  enemy  FEBA  to  each  unit 
participating  in  the  engagement  is  recalculated  (see  equation  8).  This 
distance  is  used  to  determine  whether  the  unit  is  eligible  to  discharge 
any  direct-fire  weapons;  it  is  also  used  to  determine  whether  it  should 
become  disengaged.  A unit  which  becomes  disengaged  has  its  old  movement 
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status  (i.e.,  pre-engaged  movement  code  and  data)  restored.  An  operational 
grouping  which  no  longer  contains  any  engaged  units  is  disengaged. 

The  controlling  operational  grouping  for  a given  side,  if  it  has  one, 
is  the  one  which  belongs  to  the  engagement  and  contains  a unit  farthest 
forward  in  the  direction  in  which  it  is  engaged.  This  determination  is 
made  by  examining  the  transformed  x-coordinates  of  all  units  which  are 
members  of  the  operational  grouping.  The  transformed  x-coordinate  is 
obtained  by  expressing  the  unit's  position  coordinates  in  a rotated 
coordinate  system  whereby  the  positive  x-direction  is  in  the  direction  of 
movement  of  the  operational  grouping.  The  unit  possessing  the  greatest 
transformed  x value  determines  two  important  engagement  attributes: 

1)  The  operational  grouping  of  which  it  is  a member  becomes 
the  controlling  operational  grouping. 

2)  The  X,Y  location  of  this  unit  (upon  transformation  back  to  the 
standard  Cartesian  coordinate  system),  becomes  the  updated 
center  point  of  the  FEBA. 

Thus,  the  location  of  the  controlling  operational  grouping  for  a 
given  side  determines  that  side's  engagement  FEBA. 

As  the  discussion  above  indicates,  the  location  of  the  center  point 
of  a FEBA  is  very  much  dependent  upon  the  location  of  the  controlling 
operational  grouping.  However,  an  engagement  may  involve  opposing  forces, 
in  which  one  or  both  sides  will  lack  a controlling  operational  group. 

Thus,  when  updating  FEBA  locations,  three  cases  may  arise: 

1)  Both  sides  have  controlling  operational  groupings. 

2)  One  side  in  the  engagement  lacks  a controlling  operational 
grouping. 

3)  Both  sides  lack  controlling  operational  groupings. 

The  first  case  is  handled  easily.  As  indicated  by  the  previous 
paragraph,  the  controlling  operational  grouping  for  each  side  is 
determined.  The  X,Y  locations  of  these  groupings  become  the  updated 
center  locations  for  the  respective  FEBAs. 

In  the  second  case,  the  side  lacking  a controlling  operational 
grouping  is  searched  for  an  engaged  unit  lying  nearest  the  enemy  FEBA. 
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Note  that  since  the  opposing  side  has  a controlling  operational  grouping, 
its  FEBA  location  is  uniquely  determined  by  the  controlling  operational 
grouping's  location.  If  the  search  yields  an  engaged  unit  which  is: 

1)  Participating  in  the  engagement 

2)  Farthest  advanced  toward  the  enemy  FEBA 

then  a new  FEBA  location  can  be  established  for  its  side.  The  updated 
FEBA  location  is  given  by  the  point  obtained  from  the  perpendicular 
projection  of  the  unit's  location  onto  the  engagement  axis.  This  is 
illustrated  by  equation  5.  If  there  is  no  such  unit  participating  in 
the  engagement,  then  the  search  is  extended  to  find  the  closest  engaged 
unit  not  in  this  engagement  but  within  the  scope  of  the  engagement.  The 
scope  of  the  engagement  is  a band-like  region  in  front  of  the  established 
FEBA  as  illustrated  by  Figure  5-95.  The  nearest  engaged  unit  (that  is  not 
part  of  this  engagement)  relative  to  the  enemy's  FEBA,  lying  within  the 
shaded  region  called  the  scope  of  the  engagement,  determines  the  new  FEBA 
location.  As  before,  the  point  generated  by  the  perpendicular  projection 
of  this  unit's  location  onto  the  engagement  axis,  becomes  the  updated 
FEBA  center.  If  the  extended  search  fails  to  find  an  engaged  unit,  a new 
FEBA  center  cannot  be  determined.  This  will  cause  the  engagement  to 
terminate;  all  units  parti cipating  in  the  engagement,  but  not  under 
maneuver  control,  will  have  their  movement  codes  and  movement  data 
restored  to  pre-engagement  values. 

In  the  third  case,  when  an  engagement  lacks  controlling  operational 
groupings  on  both  sides,  the  respective  FEBA  centers  are  determined  by 
finding  for  each  side,  the  unit  belonging  to  the  engagement  and  farthest 
forward  in  its  direction  of  movement  toward  the  enemy.  If  such  a unit 
exists  for  a given  side,  that  side's  new  FEBA  center  is  determined  by  that 
unit's  location.  If  neither  side  has  such  a unit,  the  engagement  is 
vacuous  and  is  terminated  immediately.  On  the  other  hand,  if  only  one 
side  has  a unit  belonging  to  the  engagement,  the  opposing  side  is  searched 
for  an  engaged  unit  which  is  not  part  of  the  engagement  but  lying  within 
the  scope  of  the  engagement.  Again,  the  scope  of  an  engagement  is  the 
band-like  area  in  front  of  the  established  FEBA  (see  Figure  5-95).  The 
nearest  engaged  unit  lying  within  the  scope  of  the  engagement  is  chosen 
to  determine  the  new  FEBA  location.  Specifically,  the  point  obtained  by 
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the  perpendicular  projection  of  the  chosen  unit's  location  onto  the 
engagement  axis  becomes  the  updated  FEBA  center. 

5 . 6 . 2 . 2 . 4 Updating  Engagement  Frontages 

The  frontages  of  each  active  engagement  is  updated  every  time-step.  It 
is  convenient  to  talk  about  hal f-trontages  since  the  model  calculates  the 
half-widths  of  each  frontage  per  engagement.  The  half-frontage  for  a given 
side  is  computed  by  considering  all  its  non-defunct  engaged  units  which  are 
eligible  to  fire  direct-fire  weapons.  For  each  such  unit,  the  perpendicular 
distance  from  its  location  to  the  engagement  axis  is  determined.  If  the  unit 
is  deploying  in  the  engagement  (movement  code  3),  the  perpendicular  distance 
is  taken  from  the  unit's  deployment  point  to  the  engagement  axis.  In  either 
case,  the  resulting  perpendicular  distance  is  added  to  one-half  the  width  of 
the  unit.  This  overall  distance  represents  the  half-width  of  the  frontage 
produced  by  the  unit.  After  all  such  distances  have  been  computed  for  one 
side,  the  largest  distance  is  chosen  to  be  that  side's  new  engagement  half- 
frontage . The  updated  frontage  is  obtained  by  doubling  the  distance  given 
by  the  new  half-frontage. 

Note  that  if  one  side  of  an  engagement  consists  of  a single  unit,  the 
half-frontage  for  this  side  is  given  by  half  the  unit  width.  In  other  words, 
its  engagement  frontage  will  span  the  entire  width  of  the  lone  unit.  Generally 
an  engagement  consists  of  two  frontages,  one  for  the  red  forces  and  one  for  the 
blue  forces.  However,  there  are  instances  when  an  engagement  will  contain  only 
one.  If  an  already  engaged  operational  grouping  or  unit  becomes  involved,  as 
a non-initiator,  in  another  engagement  (i.e.,  it  is  being  attacked  by  another 
enemy  force  thus  forming  a one-sided  engagement),  its  engagement  frontage  is 
set  to  zero  indicating  a non-existent  frontage. 

5 . 6 . 2 . 3 Determining  Direct-Fire  Eligibilities 

Each  unit  currently  involved  in  an  engagement  is  examined  to  determine 
whether  it  is  eligible  to  fire  its  direct-fire  weapons.  A unit  which  is  a 
member  of  a controlling  operational  grouping,  or  an  engaged  unit  whose  side  is 
without  a controlling  operational  grouping  will  be  permitted  to  discharge  its 
direct-fire  weapons  if  at  least  one  of  the  following  conditions  hold: 

1)  The  distance  between  the  unit  and  the  enemy  FEBA  is  less  than 
the  engagement  range  for  that  unit 
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2)  The  unit  is  moving  under  maneuver  control 

3)  The  unit  is  a member  of  an  operational  grouping 

If  a unit  belongs  to  an  operational  grouping  other  than  the  controlling 
one,  it  must  lie  forward  of  the  control  grouping's  rear  boundary  and  satisfy 
at  least  one  of  the  above  three  conditions  in  order  to  be  eligible  to  use  its 
direct-fire  arms.  Such  a unit  which  does  not  lie  forward  of  the  control 
grouping's  rear  boundary  is  immediately  eliminated  from  direct-fire  eligibility. 

5 . 6 . 2 . 4 Determining  Disengagement 

During  each  time-step,  the  range  from  an  engaged  unit  to  its  enemy  FEBA  is 
computed.  This  range  is  used  to  determine  the  unit's  eligibility  to  fire  direct- 
fire  arms  as  discussed  above.  The  range  is  also  used  to  determine  whether  an 
engaged  unit  will  become  disengaged.  Specifically,  an  engaged  unit  which  satis- 
fies all  of  the  following  three  criteria  will  become  disengaged: 

1)  The  distance  between  the  unit  and  the  enemy  FEBA  exceeds  the 
engagement  range  for  the  unit 

2)  The  unit  is  not  moving  under  maneuver  control 

3)  The  unit  is  not  a member  of  an  operational  grouping 

Disengagement  entails  a restoration  of  pre-engagement  movement  code 
and  movement  data  values. 

Engaged  operational  groupings  are  examined  each  time-step  to  ascertain 
whether  disengagement  is  appropriate.  If  an  engaged  operational  grouping  con- 
tains no  units  which  are  within  engagement  range  of  their  enemy  FEBAs,  disen- 
gagement is  in  order.  Specifically,  the  old  pre-engagement  movement  code  and 
movement  data  values  of  the  grouping's  forwardmost  unit  are  used  to  update  the 
grouping's  movement  status.  When  an  operational  grouping  is  made  unengaged 
each  and  every  member  unit  has  its  old  pre-engagement  movement  code  and  move- 
ment data  values  restored.  Thus,  disengagement  consists  in  changing  the  move- 
ment status  of  the  operational  grouping  as  well  as  the  movement  statuses  of 
each  unit  contained  in  the  grouping. 

5.6.3  Assumptions  and  Data  Sources 

The  assumptions  used  in  constructing  the  Engagements  Module  are: 


I 
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1)  The  most  important  considerations  as  far  as  whether  a given  unit 

will  join  an  engagement  or  initiate  a new  engagement  are:  visuai 

detection  and  distance.  Other  considerations  include:  maneuver 

control  status,  intent  of  unit,  whether  it  is  a member  of  an  opera- 
tional grouping,  and  unit  movement  code. 

2)  In  modeling  an  engagement,  the  most  important  attributes  are  used 
to  construct  parallel  reference  lines  called  FEBAs  which  are  used 
to  govern  ground  movement  and  ground  fire  decisions. 

3)  Each  side  in  an  engagement  may  be  made  up  of  a: 

a)  Single  unit 

b)  Group  of  individual  units  (not  in  an  operational  grouping; 

c)  Single  operational  grouping 

d)  Set  of  operational  groupings 

In  cases  (c)  and  (d),  a controlling  operational  grouping  exists  and  is 
determined.  Controlling  operational  groupings  determine  the  characteristics 
of  that  side's  FEBA. 

4)  The  unit  which  is  forwardmost  towards  the  enemy  establishes 
the  FEBA  location  for  that  unit's  side.  If  the  unit  is  a 
member  of  an  operational  grouping,  then  that  operational 
grouping  becomes  the  controlling  operational  grouping  for 
that  side. 

5)  Units  change  from  an  unengaged  movement  code  to  an  engaged 
movement  code  only  by  automatic  means  (built-in  software); 
i.e.,  they  cannot  be  directed  to  make  such  a change  inter- 
actively through  maneuver  control . 

6)  Units  which  are  members  of  an  operational  grouping  have  pre- 
determined (by  user  input)  deployment  locations  relative  to 
a point  defined  by  one  of  the  following: 

a)  The  operational  grouping's  location  as  determined  by 
its  forwardmost  unit, 

b)  The  operational  grouping's  location  as  determined  by 
the  x-coordinate  of  the  forwardmost  unit  and  the  mean 
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y-coordinate  of  all  units  in  the  grouping. 

The  choice  is  dictated  by  whether  the  operational  grouping  is  actually 
deployed  (b)  or  is  moving  intending  to  deploy  (a). 

7)  An  operational  grouping  is  not  considered  deployed  and  in  an 
engagement  until  every  member  unit  has  reached  its  pre-determi ned 
deployment  location.  As  each  unit  of  the  operational  grouping 
reaches  its  deployed  location,  its  movement  code  is  automatically 
changed  to  4 unless  specifi  y directed  to  another  unengaged 
value  (i.e.,  by  maneuver  control).  When  all  units  of  an 
operational  grouping  have  deployed,  the  movement  code  of  each 

is  changed  automatically  to  1 unless  the  movement  code  of  the 
operational  grouping  has  been  changed  to  some  value  other  than 
3 or  4 in  the  meantime. 

8)  If  an  operational  grouping  or  unit  is  engaged  when  an  opposing 
force  has  arrived  (movement  codes  10  or  14),  the  arriving  force 
will  usually  join  the  engagement;  it  may,  however,  elect  to 
start  a new  engagement  depending  on  its  position  relative  to 
the  friendly  FEBA  and  other  enemy  units.  An  arriving  unit 

which  confronts  an  unengaged  opponent  will  start  a new  engagement. 

9)  Engaged  units  are  eligible  to  discharge  their  direct-fire  arms 
against  the  enemy  if  they  are  within  certain  range  of  the  enemy 
FEBA.  Specifically,  the  following  holds: 

a)  Units  not  part  of  an  operational  grouping  must  be 
within  engagement  range  of  the  enemy  FEBA. 

b)  Units  which  are  members  of  an  operational  grouping 
but  not  in  the  controlling  operational  grouping 

must  lie  forward  of  the  rear  boundary  of  the  control  group. 

c)  Units  which  are  members  of  the  controlling  operational  grouping 
are  automatically  eligible  to  use  their  direct-fire  arms. 

10)  It  should  be  noted  that  a unit  can  be  assigned  to  only  one 
engagement  at  a time,  but  it  could  actually  be  firing 
simultaneously  on  units  involved  in  other  engagements.  It  can 
also  fire  upon  unengaged  enemy  units. 
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11)  A unit  becomes  disengaged  when  its  range  from  the  enemy  FEBA  is 
beyond  the  pre-defined  engagement  range  for  that  type  of  unit. 
Also,  an  operational  grouping  becomes  disengaged  when  none  of 
its  member  units  are  within  engagement  range  of  the  enemy  FEBA. 

Note:  All  assumptions  and  data  sources  for  the  Engagement 

Module  are  based  on  the  following: 

MAFIA  User's  Manual,  United  States  Army  Combat 
Developments  Command,  1969. 

Engineering  judgement  at  TRW. 

5.6.4  Equations 

t The  important  tactical  and  physical  mathematical  equations  used 

by  the  Engagements  Module  are: 

1)  Determination  of  new  X,Y  location  for  the  weapon  unit. 

Given  the  following  quantities: 

a)  The  X,Y  location  (IXY)  of  the  weapon  unit:  (XpY^), 

b)  The  direction  of  movement  (PDIR)  of  the  weapon  unit: 

(sin  e , cos  e ) , 

c)  The  distance  D to  be  traversed  by  the  unit  while  moving 
at  speed  R (ROMU)  during  the  current  time-step: 

D = RT,  where  T = 1 minute. 

The  new  X,Y  location  for  the  unit  ( x2 » Y^ ) is  given  by 
the  following  equation: 

X^  = Xi  + Dcos  e 

Y^  = Y^  + Dsin  e 

2)  Determination  of  the  distance  between  the  weapon  unit  and 
a target  unit. 

Given  the  following  quantities: 

a)  The  X,Y  location  (IXY)  of  the  weapon  unit:  (XW.YW), 

b)  The  X, Y location  (IXY)  of  the  target  unit:  ( Xy ,Yy ) , 
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D = Vuu  - XT)2  + (Yu  - Yt)2 


The  distance  D is  compared  with  the  weapon  unit's  engagement 
(NGARNG)  and  must-fight  (MFIGHT)  ranges  to  determine  whether 
initiation  of  a new  engagement  is  possible. 

3)  Determining  the  forwardmost  unit  (toward  the  enemy)  in  the 
direction  of  movement  (which  coincides  with  the  direction  of 
the  engagement  axis  when  the  unit  is  engaged). 

Given  the  following  guantities: 

a)  The  X,Y  location  (IXY)  of  the  unit:  (X,Y), 

b)  The  direction  of  movement  (PDIR)  of  the  unit:  (sin  e,  cos  e), 

c)  The  matrix  of  transformation  used  to  express  the  X,Y 
location  of  the  unit  in  a rotated  coordinate  system 
having  the  positive  X-axis  coinciding  with  the  direc- 
tion of  movement  is: 

(cose  -sinei 
sine  cos  e / 

The  unit  location,  expressed  in  terms  of  the  rotated 
system  is  given  by  (X^,Y^)  as  follows: 

(X,Y)  /cose  -sineV  (Xcose  + Ysine  , -Xsine  + Ycose  ) = (X^Y1) 
l sine  cos  el 

Specifically,  X^  = Xcose  + Ysine 
Y^  = -Xsi n e + Ycos  e 

Every  unit  per  side  involved  in  the  engagement  has  its  loca- 
tion expressed  in  the  rotated  system.  The  unit  having  the 
largest  abscissa  value  (i.e.,  the  largest  X^  value)  is  deter- 
mined to  be  unit  furthermost  advanced  towards  the  enemy. 

4)  Determining  the  direction  of  the  engagement  axis. 

Given  the  following  quantities: 

a)  The  FEBA  center  (IFEBAB)  of  the  blue  force:  (X^.Y^) 
b)  The  FEBA  center  (IFEBAR)  of  the  red  force:  (X^.Y^) 
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The  direction  (DIREAX)  of  the  engagement  axis  (A-|,A2)  is  given  by: 


Y - Y 

A,  = 'R  tB 
D 


A0  = XR  ' XB 
^ D 


where:  D = >(Y R - Yg)2  + (XR  - Xg)2 


Note  that  the  direction  of  the  engagement  axis,  by  convention, 
is  always  taken  from  the  blue  FEBA  center  to  the  red  FEBA 
center.  This  implies  that  with  respect  to  the  red  force,  the 
direction  of  movement  in  the  engagement  (i.e.,  from  red  FEBA 
center  to  blue  FEBA  center)  is  given  by  (-A-j,-A2). 

5)  Determine  FEBA  center  location  by  perpendicular  projection  onto 
the  engagement  axis  of  the  forwardmost  unit  not  in  the  engage- 
ment, but  located  within  an  area  called  the  scope  of  the  engage 
ment. 

Given  the  following  quantities: 

a)  The  FEBA  center  location  (IFEBAR)  of  the  enemy  force:  (Xp,Yp) 

b)  The  location  (1XY)  of  unit  lying  within  the  scope:  (X,Y) 

c)  The  direction  (DIREAX)  of  the  engagement  axis:  (sin  o,  cos  e) 

The  FEBA  center  (IFEBAB)  location  (Xp,Yp)  for  the  friendly  unit  is 


given  by: 


B2  " B1 
A2  ' A1 


Yp  = A,Xp  + 


where: 


M1  cos  6 


-COS0 


B1  - VE 


B2  = Y - A?X 


I 
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6)  Determination  of  engagement  half-frontage. 

Given  the  following  quantities: 

a)  The  FEBA  center  (IFEBAB)  location:  (XpYp) 

b)  The  direction  (DIREAX)  of  the  engagement  axis:  (sin  , cos  ) 

c)  The  location  (IXY)  of  the  unit  involved  in  the  engagement:  (X, 

d)  The  width  (1UW1D)  of  the  unit:  W 

The  half-frontage  (IBFRNT)  D for  a given  unit  is  obtained  from  the 
fol lowing  equation: 


where : 


X 


o 


y (X-XQ)2  + (Y-Yq)2 


h± 

A2-A 


1 

1 


Y 

o 


A,X  + B, 
1 o 1 


sin  8 
1 cos  0 


-cos  e 
2 sin  0 


= yf  - A]xe 


b2  = Y-A2X 


Each  and  every  unit  on  one  side  of  the  engagement  has  a half- 
frontage distance  D associated  with  it.  This  distance  is  the 
perpendicular  from  the  unit  location  to  the  axis  of  engagement 
plus  half  the  unit  width.  The  unit  producing  the  largest  such 
distance  D determines  that  side's  engagement  half-frontage. 

7)  Determining  close-support  fire  region  during  the  engagement. 

Given  the  following  quantities: 

a)  The  hal f-frontage  ( 1RFRNT,  IBFRNT)  of  the  red  and  blue  forces 
participating  in  the  engagement: 

b)  The  depth  (IENDP1,  IENDP2)  of  the  region  in  an  engagement,  in 

which  close-support  targets  may  be  assigned:  D, 

The  close-support  fire  region  A is  given  by  the  rectangular 


area  described  by  the  following  equation: 
A = (2  x H)  x B 
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where:  H = min  | HR)Hg 

8)  Computation  of  range  (IXPIIIR,  IXPHIG)  to  enemy  FEBA. 

Given  the  following  quantities: 

a)  The  unit  location:  (X,Y) 

b)  The  abscissa  value  of  the  center  location  of  the  enemy 
FEBA  is  a rotated  coordinate  system  whereby  its  positive 
x-axis  coincides  with  the  direction  of  the  engagement  axis: 

fR  (red  FEBA),  <>B  (blue  FEBA) 

c)  The  direction  of  the  engagement  axis:  (sin  e,  cose) 

The  range  R from  a given  unit  to  the  enemy  FEBA  is  given 
by  the  following  equations: 

1-fD  - (Xcose  + Ysin0),  if  enemy  FEBA  is  red 
R 

-<PD  + (Xcose  + YsinP),  if  enemy  FEBA  is  blue 

D 

9)  Determining  the  location  of  an  operational  grouping. 

Given  the  following  quantities: 

a)  The  X,Y  coordinate  values  (IXY)  of  each  member  unit  in  the  Jth 

operational  grouping:  (X,  ,Y.  ) 

Ji  Ji 

b)  The  total  number  of  units  comprising  the  Jth  operational 
grouping:  N (i.e.,  1 < i < N) 

c)  The  location  of  the  forwardmost  uni t ( IFtlUtl(O) ) for  the  Jth 
operational  grouping:  (Xj  ,Yj  ) (1  < f < N) * 

d)  The  direction  of  movement  of  the  Jth  operational  grouping: 

(sin  0,  cos  0 ) 

The  location  ( IXYOG)  of  the  Jth  operational  groupinq  (X,,Y,)  is 

d J 

determined  in  one  of  two  ways: 
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( 1 ) I f the  Jth  operational  grouping  is  not  engaged  and 
not  actually  deployed,  its  location  is  given  by  its 
forwardmost  unit: 


(2)  If  the  Jth  operational  grouping  is  engaged,  or  deployed 
or  in  the  process  of  deploying,  its  location  is  given  by 
the  following  equations: 

Xj  = ^cos  9 - Bsin  0 
Yj  = ^s  i n e + 8cose 

where:  = X,  cose  + Y,  sine 

f Jf 

N N 

(-sine)(£x,  ) + (cose)(tv1  ) 

e. mA. 

N 

10)  Determining  the  deployment  location  for  a member  unit  relative  to  the 
location  of  the  operational  grouping. 

Given  the  following  quantities: 

a)  The  current  location  (IXYOG)  of  the  operational  grouping:  (X,Y) 

b)  The  direction  of  movement  of  the  operational  grouping: 

(sin  9 , cos  e ) 

c)  The  member  unit's  planned  (by  input)  location  expressed 

„ in  a coordinate  system  centered  at  the  location  of  the 

operational  grouping:  (x\y^);  X^  is  the  forward  dis- 

tance from  the  current  location  of  the  operational 
grouping  (positive  in  the  direction  of  movement  of  the 
grouping),  Y^  is  the  lateral  distance  from  the  current 
location  of  the  operational  grouping  (positive  to  the 
It  ft  and  negative  to  the  right  when  facing  forward), 


J 
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d)  The  expansion-contraction  factor  (FECFAC)  for  the  operational 
grouping  during  deployment:  F 

The  following  equations  give  the  coordinates  of  tne  deploy- 
ment location  (Xq,Yq)  for  the  member  unit: 

XD  = X + X]cos  9 - (Y]sine)F 

Yq  = Y + X1  sin  9 + (y^osejF 
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5.7  INPUT/OUTPUT  MODULE 

5.7.1  Input  Submodule 

5.7.1 .1  Operation 

The  operation  of  the  Input  Submodule  is  simple  and  straightforward. 

It  reads  the  data  needed  to  run  the  model  from  the  various  data  disk  files 
using  Fortran  read  statements,  namelist  INPUT  statements  and  calls  to  the 
Fortran  routines  BUFFERIN  and  BUFFIN.  The  Input  Submodule  also  packs  data 
(puts  more  than  1 piece  of  data  in  1 word  of  core)  and  initializes  many  of 
the  arrays  to  zero.  The  significance  of  the  Input  Submodule  is  that  it 
allows  the  CATTS  model  great  flexibility  since  much  of  what  the  model  does 
is  controlled  by  the  input  data.  This  allowed,  for  example,  the  obsolete 
90MM  Recoil  less  Rifle  to  be  replaced  by  the  Dragon  missile  in  the  data  base 
without  changing  a single  line  of  the  math  model  code.  If  the  equipment, 
units,  weapon  effects,  etc.,  were  described  in  the  code  instead  of  in  the 
data  base,  the  replacement  of  one  type  of  equipment  with  another  would  be 
much  more  difficult  and  expensive  than  it  is  in  CATTS.  In  addition  to 
equipment,  a large  amount  of  the  tactically  significant  items  are  controlled 
and  input  via  the  data  base.  These  include  the  relief,  soil,  vegetation, 
weather,  and  lighting  conditions  of  the  area  of  operations,  the  sensor  types 
and  placement,  the  unitsJ  TOE's  and  position,  the  weapon  accuracy  and  effects 
data,  tasking  organization,  modes  of  equipment  operation,  movement  and  change 
of  state  data,  suppression  data,  and  so  on.  Figure  5-100  shows  the  subroutine 
linkages  for  the  Input  Submodule,  while  Table  5-47  gives  a brief  description 
of  each  routine  and  its  major  inputs  and  outpits. 

All  the  data  needed  to  initialize  and  run  the  CATTS  math  model  is  on 
disk.  Basically  there  are  9 data  files  needed  to  initialize  and  run  the 
CATTS  math  model  (there  are  other  disk  files  needed  to  run  associated  with 
other  modules  - the  background  events  file  associated  with  the  events  module, 
for  example). 

The  data  files  are: 

1 terrain  relief  file 
1 elevation  displacement  file 

(needed  only  to  pack  the  terrain  relief  data) 


1 soil  data  file 


Table  5-47.  Input  Submodule  Subroutine  Descriptions 
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Table  5-47.  Input  Submodule  Subroutine  Descriptions  (Continued) 


Page  5-660 


I 


AD-A038  798 


UNCLASSIFIED 


TRW  DEFENSE  AND  SPACE  SYSTEMS  GROUP  REDONDO  BEACH  CALIF  F/G  15/7 
MATHEMATICAL  MODEL  USER  * S MANUAL  COMBINED  ARMS  TACTICAL  TRAININ— ETC (U) 
JAN  77  D S ADAMSON*  E C ANDREANI*  G W ARCHER  N61339-73-C-0156 

NAVTRAEQUIPC-73-C-0156-EOO  NL 


2 S 

AQAO 38798 

B 

|M| 

f i,  Bi!«  : 

m 

1 

11  i 

ss^=z- 

Bt*- 

■ 

\ — 

Page  5-674 


7a'  le  5-47.  Input  Submodule  Subroutine  Descriptions  (Continued) 


Page  5-661 


k. 


Table  5-47.  Input  Submodule  Subroutine  Descriptions  (Continued) 


Page  5-662 


Table  5-47.  Input  Submodule  Subroutine  Descriptions  (Continued) 


r i 

Page  5-663 


> — A 


idle  5-<7.  Input  Submodule  Subroutine  Descriptions  (Continued) 


| 


1 


r 


Page  5-665 


Page  5-666 


<♦“  I 
05 
(I)  i. 
O x u 
4-»  o 
c o 
o «♦- 
•«-  o o 

to  O 

•--CO 

o)  u rs 
> <r  — « 


K-  <D  U 

K-  C •*-» 

<0  01 
o c 

•*-»  • o 

0>  r-  Q)  -r-  1 

- X3  C 

O'"-  o -r-  « 

C tO  1 

•r*  O)  0)  O ' 

i/)  Q.  ll  QS 
>»  >* 

lO  P f>  D ' 


O O 4-*  4->  C 


^ 0) 

E <D 
Q.  x: 

V-  ■ r—  4~* 

O 3 
Q.  CT  ifl 
(1)  (U  P 


cr  4-» 

a»  <x> 


4-> 

SI 


3 

o 


cx 

c 


a. 


o ct  to 
ro  • — • -*— » 

CLU_  •»- 

f z -a 
+->  Cl 
•r-  3C  o 
03  CO 


I 


c •* 
a;  03 

to  E E o 
D a a c 
tr  -r-  M-  <v 
O 3 3 N 

a cr  cr 

OJ  d)< 


4->  U 

to  O 
o)  o 
o 

cr  <D 
oj  x 

u 4->  4->  u 


<V  O <L> 

n qq 
>t  o >* 


£ 


§ 

X3 

13 


O 0)  ^3 

, 

■■"-in 

x:  -f-~ 

a. 

o 

o 

O QJ 

4-5 

0)  X >,  X 

u 

to 

Q)  to 

c 

4-5  (U  4-»  0) 

4-» 

X 03 

05 

CO  03 

05  • 

>>  -O  T3 

c 

5 X 

u 

> T3 

CO  C 0)  c 

o 

4-> 

3 

4-> 

ai  a» 

r-  U r- 

o 

w. 

to 

O 03 

to 

3 

' — ^ 

o •*> 

03 

Q.  4-> 

*4—  tO 

• T3  to  T3 

x:  o 

t4-  o 

0) 

C 03 

O QJ 

>,  C 03  C 

4-5  O 

L. 

b 

— « Q 

U 

03  3 O)  3 

1 r— 

•—  QJ 

■xj  O 

t-  O E O 

2:  vi 

»S5 

r— 

to  0) 

4-'  L. 

u u u 

O 5 

*4—  1 

o 

*•>  X 

03  Cl 

03  CT>r—  CD 

• O 

o c 

u 

o 4-> 

T3 

-iC  O 0) 

►— * 

o 

4-5 

0) 

O' 

0D  u u U 

*4-  VI 

05  C 

c 

4-  t*.. 

0)  C 

05  03  4-5  o 

O r— 

3 

o 

^ o 

U -f- 

c.  **- 

' 

i — to 

u 

UJ 

•r-  0) 

o o 

c 

03  *r» 

r— 

p n to 

03  0)  O to 

o 

> 

t4— 

C 1 

o vi 

CL  XT  03 

O 

O CO 

C tflh 

i 4-j  0)  x:  lo 

4-5  05 

4-5  . 

a. 

•«-  >» 

05  XI  CO 

— t_ 

to  *• 

u 

03  0) 

4->  UJ 

4->  vO  4-5  XL  V1 

C 3 

05  r— 

05 

<35 

c *->  n 

>»  05  o ►— 

•r~  tO 

X — - 

X 3 

3S  -Q 

05  03  vi 

X3  > U -f-  VI 

t4—  03 

ct3 

b 

03 

> X r- 

r-  O -C  f- 

05  05 

•r-  t_J 

3 

b- 

-- — ■. 

UJ  

< cnt*-  5 " 

Q E 

z >— 

C 

O 

t*~ 

#— 

1 

i 

• 

1 

c o 

03 

o 

3 

C 

4-5  rv. 

03 

a.  i 

5 

^ — . 

•r-  O 

*— < 

- — - 

U v£> 

to 

> 

v <• 

51 

O 

c 

UJ 

s: 

O 

to  to 

O 

o 

►— * 

0)  ai 

•r— 

Lt_ 

•> 

X3  cr*  •»-> : 

h- 

O 

r3 

1 — 

03 

03 

O) 

O 

CL 

> — - 

2" 

a>  Cl 

L 

c 

>- 

5: 

O 

O' 

05  , 

o 

Z 

r-* 

o 

o 

c/1  c 

CL| 

z 

3e: 

z 

'-'OOl 

4-3 

4-5 

4-> 

3 

4-> 

3 

3 

a. 

3 

Cl 

o 

4—* 

Q. 

4-5 

c 

3 

C 

3 

*“4 

o 

o 

0-  to 

o 

o 4-> 

4-5  1 

c 

o 

4->  0) 

to  u 

0)  •— 

4-5  d 

to  U 

C 

• r— 

0)0  0) 

> 4-5  to 

<4- 

<D  1 0 

- 0) 

■O  X) 

0)  O 

r-  0) 

O to  03 

-O 

U 3 4-> 

4-»  03 

b 03 

C O "O 

• r— 

O to 

CL  O 

U r—  05 

3 0) 

<1  x 

l Cl 

T3  4-5 

-*  to 

c 

o 

03  • 03 

O X) 

tO  •#- 

-J  c 

X3  05  > 

vO 

c u 

to 

03  3 4-» 

4-»  to 

C 

E to  3 

O -*-> 

o 

E os  a 

05  C 

O O)  c 

0-  0) 

4-3 

a E -r- 

UJ  u 


QJ  i — to 
>0  0) 
•r-  i-  U 


O O— 

4-5 

4-5 

3 

CL  QJ 

4-5 

O 

C 

to 

03  O 

U 

03 

o 

03 

05  O 

0) 

L- 

o 

0) 

3 

t*- 

0) 

E 

4-5 

*4— 

4-5 

0) 

0)  o 

0) 

c 

4-> 

r— 

X 0) 

■ r— 

05 

o 

4-5  t*_ 

c 

r— 

u 

t*— 

o 

to 

o> 

4-> 

C 05 

CL 

O) 

TD 

c 

1/3 

lO 


0)  0)  o 
a jv 


0)  o 

o to 
O T3  to 
U X)  0) 
Q.  itJ  U 


•W  I 


oo 

p 

z 

o 


3 


Page  5-668 


SMFU(JU)  - Area  support  fire  weapon 

rounds/unit  time  received  by 
unit  JU.  (IsJUslOO) 


Table  5-47.  Input  Submodule  Subroutine  Descriptions  (Continued) 


Page  5-669 


1 


Page  5-671 


2 vegetation  files 
1 card  image  scenario  file 
1 binary  scenario  file 
1 prescheduled  events  file 
1 pre-planned  mission  file 

One  additional  data  file,  not  needed  to  run,  but  used  for  configuration 
control  is  the  baseline  card  image  scenario  file.  This  file  serves  as  the 
beginning  point  for  all  changes  to  the  scenario  but  is  never  changed  until 
all  the  changes  have  been  tested  and  used  for  running  a game.  This  file 
contains  the  same  type  of  information  as  the  card  image  scenario  file.  The 
binary  scenario  file  contains  the  same  information  as  the  card  image  file, 
but  in  a different  format  which  allows  a much  quicker  initialization  than  the 
card  image  format.  All  the  detailed  information  about  all  of  the  data  files 
i.e.,  where  the  files  are  on  the  disks,  what  specific  data  is  contained  in 
each  file,  what  the  format  of  the  data  is,  and  which  scalars  and  arrays 
(tables)  the  data  goes  into  is  contained  in  the  Data  Base/Operations  Manual. 
But,  in  general,  the  terrain  relief  file  and  elevation  displacement  file  con- 
tain the  elevation  data  (some  4 million  points)  for  the  area  of  operation. 

The  soil  data  file  contains  the  location  of  the  soil  types  throughout  the  area 
of  operation.  One  of  the  vegetation  files  contains  the  X,Y  locations  of  the 
vegetation  polygons  in  the  area  of  operations  and  the  other  vegetation  file 
contains  descriptions  of  the  vegetation  classes  themselves  (the  description 
of  the  soil  classes  is  input  via  the  UGS  input  deck  on  the  scenario  file). 

The  scenario  file  contains  all  taccical  data  that  is  not  terrain,  soil,  or 
vegetation.  This  includes  data  on  equipment,  ammunition  types,  sensor  types, 
UGS  types  and  locations,  radar  types,  unit  types,  unit  TOE's  and  locations, 
tasking  organization,  minefield  location,  roads,  suppression,  control  measures, 
weather,  pre-planned  missions,  etc.  The  method  of  updating  the  scenario  file 
is  detailed  in  Section  4 of  the  Data  Base/Operations  Manual . The  binary  sce- 
nario file  contains  the  same  information  as  the  card  image  scenario  except 
the  data  is  in  5 records  each  approximately  16,000  words  ’ong  (the  card  image 
scenario  files  are  in  approximately  4000  records  each  20  words  long).  The 
prescheduled  events  file  contains  events  which  will  occur  every  time  the  sce- 
nario is  run.  These  events  are  put  on  this  file  via  punched  cards  or  an 
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initialization  procedure  that  puts  events  input  during  initialization  onto 
this  file  - see  Data  Base/Operations  Manual.  Appendix  B.  A sample  pre- 
scheduled events  file  is  shown  below. 

Sample  Prescheduled  Events  File 

(with  one  fire  event  (Type  10)  and  one  maneuver  event  (Type  9)) 

NEVTP  = 2, 

★ 

ITMEVE  = 0, 

I VDT  = 10,  1,  25,  17,  2,  1,  201,  6,  64750,  19900, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  2, 

* 

ITMEVE  = 15, 

I VDT  = 9,  10,  24,  3,  0,  0,  1,  55600,  21200, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  C,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0.  0,  0, 

0,  0,  0,  2, 

* 

Th«  pre-planned  mission  file  contains  the  pre-planned  missions  to  be  exe- 
cuted during  the  simulation.  This  file  is  filled  with  data  by  the  computer 
during  initialization  using  data  from  the  pre-planned  mission  deck  on  the 
scenario  file. 

The  data  flow  from  the  disk  files  to  the  computer  core  memory  for  use 
by  the  math  model  is  shown  in  Figure  5-101.  The  exact  checklist  procedures 
for  initializing  the  simulation  including  sense  switch  3 and  I SAVE  I NP  are 
contained  in  Appendix  B of  the  Data  Base/Operations  Manual.  Thus,  the  follow- 
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Figure  5-101.  Data  Base  Information  Flow  (Example  For  Scenario  BIG) 
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ing  discussion  is  an  attempt  to  give  the  user  the  reasons  and  theory  behind 
the  different  files  and  procedures. 

The  data  base  is  kept  on  disk  because  tape  or  cards  are  both  much  slower 
to  read  in  and  are  much  bulkier  to  handle.  The  card  image  scenario  file  looks 
like  cards,  in  fact  (80  characters  or  20  words  per  record),  and  takes  approxi- 
mately 5 minutes  to  read  the  approximately  4000  records  (cards)  comprising  this 
file.  If  the  scenario  file  were  actually  on  cards,  the  time  needed  to  input 
this  same  information  would  be  even  greater.  The  binary  scenario  file,  because 
it  is  read  in  by  BUFFERIN  in  5 records  each  approximately  16,000  words  long, 
takes  less  than  1 second  to  input  this  same  information.  Thus,  SSW3  should  be 
on  when  changes  have  been  made  in  the  card  image  scenario  file  and  I SAVE  I NP  is 
set  equal  to  1 to  insure  the  creation  of  a new  binary  file.  Also,  a new  bi- 
nary scenario  file  should  be  created  when  any  common  block  definition  or  data 
statement  in  the  root  or  segments  1,  2 or  3 of  the  overlay  structure  are 
changed.  Normally,  only  for  testing  purposes  would  a user  turn  SSW3  on  to 
read  the  card  image  scenario  and  not  set  ISAVEINP  to  create  a binary  copy  of 
the  scenario  file.  Also  note  that  if  SSW3  is  off  but  ISAVEINP  is  set  equal 
to  1,  a new  binary  scenario  file  will  be  created  from  the  old  binary  scenario 
file  with  the  only  difference  between  new  and  old  being  the  variables  changed 
by  the  namelist  cards  in  the  run  deck.  This  capability  has  not  been  used  often 
in  the  past,  but  could  be  a method  of  testing  changes.  The  problem  with  this 
is  the  difficulty  in  keeping  track  of  and  documenting  changes  made  in  this  man- 
ner. 

The  only  other  data  file  in  card  image  format  is  the  prescheduled  events 
file,  and  this  was  designed  so  the  user  could  punch  up  cards  in  event  notice 
form  and  copy  them  directly  onto  this  file  and  have  the  events  occur. 

The  other  files  are  all  blocked  so  they  can  be  read  in  quickly,  the  same 
way  the  binary  scenario  file  is.  The  elevation  displacement  file  is  2250 
words  in  1 record,  the  vegetation  composition  file  is  265  words  in  1 record 
and  the  vegetation  location  file  is  2828  words  in  1 record.  These  files  are 
not  packed  but  are  in  binary  form  so  that  they  can  be  read  in,  and  with  no 
further  translation  or  packing  are  ready  to  use.  The  prescheduled  events  file, 
the  2 vegetation  files  and  the  elevation  displacement  file  are  all  read  in 
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only  once  during  initialization.  The  file  containing  the  terrain  relief  data 
and  the  file  containing  the  soil  data  are  both  read  once  each  model  time  step. 
This  has  the  disadvantage  of  slowing  down  each  model  time  step  to  read  this 
data  from  disk.  However,  this  procedure  is  necessary  because  the  information 
contained  on  these  two  files  will  not  fit  into  core  memory  and  thus,  must  be 
read  in  pieces  using  the  double  buffers  (as  shown  in  Table  5-48)  to  speed  the 
reading  of  this  data  as  much  as  possible.  Table  5-48  details  how  the  terrain 
relief,  vegetation,  and  soil  data  files  are  read  in.  Table  5-49  details  how 

t 

the  card  image  scenario  file  and  prescheduled  events  files  are  read  in,  and 
which  subroutine  creates  the  pre-planned  mission  file. 

5 . 7 . 1 . 2 Assumptions  and  Data  Sources 

The  basic  assumption  of  the  input  submodule  is  that  CATTS  should  be  a 
data  driven  model  so  that  changes  in  tactics,  unit  TOE's,  equipment,  etc. 
can  be  easily  incorporated  into  the  model. 

The  sources  of  the  data  for  the  various  files  are  many  and  varied,  as 
shown  in  the  paragraphs  following  the  tables. 
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Table  5-48.  Subroutines  that  Read  in  Relief,  Vegetation,  and 
Soil  Data  into  Arrays  for  Use  by  the  Math  Model 
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Data  is  read  in  initially  to  fill  common  blocks  and  then  not 
read  in  again.  Read  in  by  BUFFERIN. 
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Soil  Data  into  Arrays  for  Use  by  the  Math  Model  (Cont'd) 


Page  5-677 


CD 

c 

C -r- 
•r-  4J 

3 

•o  O 
CD  S- 
to  -Q 
ZD  3 
C/D 


>3  CD 
_Q  C 

C 4-> 

•r-  3 

O 

TD  ‘ 
03  -CD 
CD 
a:  c/) 


1 

C 

s: 

►—  >,  c >■ 

rO 

CD 

i/>a>otoa]Uja)Lu 

o 

C -C  O O S-U-  > — 1 

to 

OD(/) 

—J  L-  LU  CD  LU 

\Z 

•r-  O 

(T3  *—*  *— • 

(J 

1 

u 

4->  $ 1 

Ds  —I  — 1 

o 

t 

o 

4-> 

ro  CD 

L-  CD  LU  4—«  to 

o 

o 

o 

O 

o 

1— 

LU 

LU 

O 

O 

to 

r-r  QJ 

4-»  -C  DC  O >, 

CO 

Cl) 

LU 

LU 

LU 

LU 

LU 

-Q 

Ll_ 

Lu 

Lu 

Lu 

fO 

3 4->  C 

Ch  O0  ro 

> 

> 

> 

> 

> 

LU 

LU 

LU 

LU 

r— 

CJ  *r-  *r- 

<D  u 

c 

ro1 

<z 

<c 

c 

I 

c 

4—4 

M 

»— i 

M 

f—  CD  4-> 

U CD  L 

1— 

H— 

h- 

h- 

h- 

t 

o 

_J 

_l 

-J 

-J 

CD 

03  3 

Q • O »—  ro 

C 

<C 

1 

t: 

LU 

LU 

LU 

LU 

-C 

U O O 

p 

o 

o 

Q 

o 

Q 

j 

=r 

or 

DC 

DC 

DC 

4-> 

-U>  L- 

4— 4 -O  C+-  C73 

Q 

O 

1 • 

(D  CO 

CO  O C 

(_) 

< 

J 

S- 

-C  -f-  3 

C</)  CJC-r 

4—4 

CD 

4->  t0 

i-  O to  to 

ro  <d 


i E T3 
itj  o <y 

Z 5.  (A 

U-  3 
>3 

ro  ro  to 

S-  4->  -r- 

S-  fO 

<£  Q 


O) 


CD 


<4- 

O 


— J 

-J 

_J 

—J 

O 

o 

o 

o 

1/0 

CO 

CO 

CO 

o 

<-_> 

CD 

<_> 

» — t 

►H 

4—4 

4—4 

je: 

3e: 

2E 

3E: 

oO 

oO 

o0 

OO 

CO 

CO 

CO 

CO 

CO 

CO 

CO 

CO 

o 

o 

o 

o 

z 

z 

z 

z 

4—4 

4—4 

4—4 

4—4 

— 1 

—1 

_l 

-J 

4— 4 *— I 4— 4 Q_ 


o 

o 

to 

o 


o o o o 
</>  00  CO  to 


o 

4-> 

ifl  o 

> 

o 

Q. 

CL 

CL 

CL 

03  CD  -c:  1 LU 

LU 

CL 

CL 

CL 

CL 

a_ 

c 

z: 

7" 

y 

c _c  cj  _o  LU 

JZ  _J 

z 

z 

z 

z 

z 

o 

o 

o 

o 

CD  to  •r~  3 4— 4 

03  LU 

4—4 

4—4 

4—4 

4—4 

4—4 

c 

o 

o 

o 

o 

.E  0)  UJ  •!-  ^ 10  _J 

3 4-4 

CO 

CO 

CO 

CO 

CO 

CD 

to 

CO 

CO 

CO 

4->  n > t:  i uj 

o 

o 

o 

o 

o 

o 

.c 

o 

o 

o 

o 

LU  -r-  C DC 

S-  l- 

M- 

o 


CD  — I 4-  r-  -r- 
s-  lu  a_  s- 
o_  z to  o 


■*=  o 


LO 

LO  C\J 
CVJ  CVJ 
CVJ 


LT)  LO  VO 

CVJ  OJ  •* 

CVJ  OvJ  CVJ 

LT>  LO  O 

O 


>- 
O —I 
DC  O 
Cl. 

4-4  X 


o 

Cl. 

>- 


O 


>>-Q 

»—  c 

CO  *r— 
•r~ 

4->  "XD 

•r—  <0 
C CD 

•r>  QZ 


to 

OO 


1^ 

00  ^ 
to  r— 
CO  to 
i—  CO 


Ov 

00 

to 

LO 


o o 


o o o o 

LO  CO  CO  to 

1—4  '"3  4— 4 *"3 


•f~  3 

■a 

a_ 

E z: 

__  o o 

3fc  tO  «*->  O -C  o 

•r-  *r»  4->  *4-  CO 

“O  • -O  O 

CZ  «0  >3  * 3 5 ro  -J 

IQ4J  (O  C (/)  40 

<T3  t-  O TD  rO  >> 

C “O  S-  *r-  to  CD  T3  -Q 

•r—  rO  4~>  r-  4-* 

i — fxs  i — ro  • — cz 

"O  T“  O r—  (Q  *r—  *r-  •*— 

ro  O > 3 U CD  O 
<D  00  LU  U O WO 

V-  Jr-  >,  VI  rO 

QJ  LU  ro  i — to  CD  CD 


*r*  • 

•r- 

V)£m  O 0) 

<OC  L 

c 

•r-  4->  +-> 

■U> 

T3  -r- 

■o 

CD  lO  rO 

— 1 to 

ru  fT3 

rO 

(D  "-COt- 

4— 4 CZ  ro 

CD  O) 

CD 

n-  -P  -P  _JTJ 

O -r-  £ 

^ 4T3 

S- 

>r—  »r-  (D 

co  <o 

tf—  L +J  P 

•U>  ro 

to  C 

to 

C O to  E 

CD  C P 

o 

•r*  •»— 

•r— 

Lu  O rO  'f- 

c  o ro 

o 

lu  >>r— 

*r—  D "O 

_l 

ra  T3 

—1 

rO 

4— 4 CD  <0  C 

+-> 

o 

4-»  ro 

4—4 

4-> 

JO  L 0)  Qj 

3 i CD 

LU 

ru  CD 

o 

ro 

LUrOL--CZ-£Z 

O O -c 

> 

CO  $- 

CO 

Q a E rt3  -L->  -M 

LCD 

CO 

CVJ 


CVJ 


Page  5-678 


C r— 

C 4-> 

03  0) 

•r-  3 

TD 

O 

**  O 

■a  l. 

c 2: 

03  -Q 

0 

03  3 

•r-  _C= 

o'  00 

4->  4-> 

03  03 

4->  21 

03 

CJ>  03 

03  -C 

> 4-3 

0 

0 

* >> 

r— 

'4—  _Q 

CO  03 

03 

E 

■r-  03 

C 03 

1 — CO 

0 z 

03  ZD 

p 

QC 

S- 

0 

c O 

0 

•r-  4- 

T3  CO 

03  >, 

03  03 

Od  L- 

4-3 

S- 

03  03 

4-3  <3: 

-C  r— 

03 

3—  •«-  c 

-C  0 

ll.  t~ 

4-3  4-3 

03 

c 

E E “a 

CO  *r- 

03  O 03 

03 

Z S-  CO 

C 03 

Ll.  3 

•r-  4-> 

>> 

4-3  03 

03  03  CO 

3 O 

S-  4->  -r- 

O 

i-  03 

S-  *— 

<C  Q 

_Q  -r- 

3 O 

C /)  OO 

C 

SCO 

4->  O 03 
(O  U -M 
O 03 
O CTJ 


lO 

di  r l • 
C O 03  O 

03  **“  -C  _J 
r -P  m 
03  ^ 03  CD 

x:  -c  i/) 

4- >  * £ *-d 

c _j  — i -a 

•»—  LU  ►— « C 
CD  CD  03 
aj  z oo 

5-  •— « o 
O 03  —I 
O 03  C »— • 

i — *r-  O 
C XD  4->  </3 

•r  (O  3H 

•r-  O 

-o  s-  s-  s- 
OJ  03  _Q  o 
S-  > 3 

Q CO  LU 
■M  03  _J 


03  03  U 03 
T3  C-r 

TD  LU 
03  JX  C —I 
CO  O *f—  *— • 
3 O O 
03  r-  Q_  tO 

0)  o 

XD  C > CO 

§— I >> 
LU  03 

O *- 
co  a o 03 
•r-  o 

-c  >>r-  c 

H“  XD  _Q  v— 


►— « *0  *r— 

ocx: 

C/D  03  4-3 

aq 

03  LU  C 

co  s- 

C J*r 

ad  n) 

•r—  M 

r— 

4-3  0 03 

03  3 

310  L 

03  O 

O ' 03 

CO  •#- 

£ 



XD  C0  LU 

c 

=3  >>  — 1 

• 

■O  03 

I/I  OJH 

03 

C CL 

C O 

03 

03 

c s-  00 

C 

E 03 

M OJD 

03 

O 

O CO 

•r- 

Z “O 
ej 

3-J  OJ 
O LU  03 
L.  »— « L- 
-Q  03 
3 >> 

CO  03  co 
S-  *r- 
C S-  X= 
»— « 03  4-> 


L r-  • 

a o3tj 

XD  3 03 
E c 
3 03  03 

c*  8 
03  0)  r— 
U 

CO  C CO 

•r-  0)  *»- 

£ 

^ 03  CD 
*4-  r- 
• • 03  •*“ 
LL.  CC  4- 


Page  5-679 

Table  5-49.  Subroutines  that  Read  in  the  Scenario  Data  from 
the  Data  Base  Card  Image  Files  ( F : 5 ) NBIG,  NGOLD, 
etc.,  and  Prescheduled  Events  File  ( F : 1 1 ) EBIG, 
EFBAGOLD,  etc.,  for  Use  by  the  Math  Model 


Deck  Name 


Read  in  by 
Subroutine 


MISC  VARIABLE 
EQUIPMENT  INPUT 
AMMO  INPUT 
SENSOR  INPUT 
VISUAL  DETECTION 
AURAL  DETECTION 
UGS  INPUT 

GROUND  SURVEILLANCE 
RADAR  INPUT 

UNIT  TYPE 

TARGET  ACQUISITION  INPUTS 
WEAPON  EFFECTS  INPUT 
UNIT  INPUT 

OPERATIONAL  GROUPINGS 
INPUTS 

COMMAND  UNIT  INPUT 

CONTROL  LISTING  OF  UNITS 
AND  NEXT  HIGHER  COMMAND 

ENGAGEMENT  INPUT 

CHANGE  OF  STATE  INPUT 

OP  STATE  NAME 

EQUIPMENT  MODE  INPUT 

MOVEMENT  INPUTS 

FIRE  SUPPORT  INPUT 

SUPPRESSION  INPUTS 

CONTROL  MEASURE  INPUT 

MINE  OBSTACLE 
FORTIFICATION  INPUT 

ROAD  INPUT 

BRIDGE  INPUT 

PREPLANNED  MISSION 
INPUT 


NAMELIST 


INPUT 

EQINP 

AMMOINP 

SENSINP 

SENSINP 

SENSINP 

SENSINP 

SENSINP 

UTINP 

TAINP 

WEFINP 

UNINP 


OGINP 

CMDUNINP 

MKUNLIST 

ENGINP 

COSINP 

INPUT 

MUINP 

MOVINP 

FSPINP 

SIGINP 

CMINP 

OBFMINP 

ROADINP 

ROADINP 

PPLANINP 
INPUT  & I N IT 
INPUT 


All  the  data  shown  on  this 
table  is  read  in  initially 
to  fill  the  common  blocks 
and  then  not  read  in  again. 


Outputs  info  onto  preplanned 
mission  file(F:12)  PBIG, 
PF8AGOLD,  etc. 


Table  5-49.  Subroutines  that  Read  in  the  Scenario  Data  from 
the  Data  Base  Card  Image  Files  (F:5)  NBIG,  NGOLD, 
etc.,  and  Prescheduled  Events  File  (Fill)  EBIG, 
EFBAGOLD,  etc.,  for  Use  by  the  Math  Model  (Cont'd) 


The  binary  scenario  file  ( F : 1 0 ) BBIG,  BFBAGOl.D,  etc.,  is  created 
using  the  data  read  in  by  the  subroutines  listed  in  Table  5.7-2. 

The  prescheduled  events  file  ( F : 1 1 ) EBIG,  EFBAGOLD,  etc.,  is  read 
in  by  local  subroutine  GETEV  in  subroutine  INPUT. 


Page  5-681 


Following  is  a deck  by  deck  description  of  the  sources  of  the  CATTS 
data  base  on  the  scenario  file. 

MISCELLANEOUS  VARIABLE  DECK.  This  deck  consists  of  bookkeeping  numbers, 
except  for  WPVC,  which  is  the  weight  of  the  personnel  vulnerability  classes. 
This  data  is  based  on  the  MAFIA  V Data  Base. 

EQUIPMENT  INPUT  DECK.  The  sources  for  this  data  are  as  follows: 

Jane’s  Weapons  Systems , Staff  Officer  Field  Manual  FM  101-10-1 , Tactical 
Vehicles  Manual , Artillery  Handbook,  the  STANO  Handbook,  MAFIA  V Data  Base, 
Dash  1 Flight  Manuals,  and  USAREUR  Pamphlet  30-60-11  and  30-60-1. 

AMMO  INPUT  DECK.  These  numbers  are  essentially  bookkeeping  numbers  to 
give  ammunition  the  proper  name  on  the  menus  and  were  produced  by  TRW  from 
the  equipment  input  deck. 

SENSOR  INPUT  DECK.  The  sources  of  data  for  this  deck  include  Jane's 
Weapons  Systems,  the  STANO  Handbook,  Biocoustics  Labs  at  Wright-Patterson 
and  Edgewood  Arsenal . 

VISUAL  DETECTION  DECK.  The  sources  for  this  data  include  Iran  Counter- 
Infiltration  Systems  Study  and  the  STANO  Handbook. 

AURAL  DETECTION  DECK.  The  sources  for  this  data  is  the  Biocoustics  Labs 
at  Wright-Patterson  AFB  and  the  lab  at  Edgewood  Arsenal,  the  Audiology  Clinic 
at  Fort  Benning,  SIAF,  and  Technical  Discussions  with  Captain  Amos. 

UNATTENDED  GROUND  SENSOR  INPUT  DECK.  The  sources  for  this  data  include 
Terrain  Analysis  in  Support  of  CATTS  by  the  Defense  Mapping  Agency  Topograph- 
ical Center. 

GROUND  RADAR  INPUT  DECK.  The  sources  for  this  data  include  Technical 
Discussions  with  Reinhart  Olesch  and  the  STANO  Handbook. 

UNIT  TYPE  INPUT  DECK.  Sources  for  this  data  include  the  GFP  Scenario 
Package,  Handbook  on  Aggressor  Military  Forces.  Aggressor  Order  of  Battle 
Book,  and  the  Operations  and  Training  Handbook. 

TARGET  ACQUISITION  DECK.  This  is  not  used  by  CATTS. 

WEAPON  EFFECTS  INPUT  DECK.  This  data  was  derived  from  the  MAFIA  V Data 
Base,  and  TRW  Engineering  Estimates.  ADA  weapon  effects  data  was  furnished 
by  Captain  Larry  Lippincott,  and  air  to  ground  weapon  effects  data  was 
furnished  by  Colonel  Gardner,  both  in  discussions  at  Fort  Benning  in  1975. 


A 
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UNIT  DESCRIPTION  DECK.  Data  sources  for  this  deck  include  GFP  Scenario 
Package,  Handbook  on  Aggressor  Military  Forces,  Aggressor  Order  of  Battle 
Book,  Infantry  Reference  Data,  GFP  Tables  of  Organization  and  Equipment  (H 
Series),  Memorandums  from  Colonel  McGili cuddy  and  Colonel  Franklin,  and 
Type  Corps  Troop  List. 

OPERATIONAL  GROUP  INPUT  DECK.  The  data  for  this  deck  came  from  the  GFP 
Scenario  Package  and  the  MAFIA  V Data  Base. 

HIGHER  AND  ADJACENT  INPUT  DECK.  The  data  in  this  deck  came  from  the 
GFP  Scenario  Package  and  several  of  the  memorandums  and  discussions  with 
Fort  Benning  personnel. 

CONTROL  DECK  FOR  THE  LIST  OF  UNITS  ON  THE  MENU.  The  source  data  for 
this  deck  includes  the  GFP  Scenario  Package,  and  several  memoranda  and 
discussions  with  personnel  at  Fort  Benning. 

INITIAL  ENGAGEMENT  DECK.  The  source  of  data  for  this  deck  was  the 
MAFIA  V Data  Base. 

UNIT  OP  STATE  DECISION  CONTROL  DECK.  The  source  of  data  for  this  deck 
was  the  MAFIA  V Data  Base  and  TRW  Engineering  Estimates. 

OPERATIONAL  STATE  NAME  INPUT  DECK.  The  source  of  this  data  was 
discussions  with  personnel  at  Fort  Benning. 

DECK  TO  CONTROL  HOW  OPERATIONAL  STATES  WORK.  The  source  of  this  data 
is  discussions  with  personnel  at  Fort  Benning,  the  MAFIA  V Data  Base,  and 
TRW  Engineering  Estimates. 

MOVEMENT  CODE  CONTROL  DECK.  The  source  of  this  data  is  the  MAFIA  V 
Data  Base. 

FIRE  SUPPORT  CONTROL  DECK.  The  source  of  this  data  is  the  MAFIA  V Data 

Base. 

SUPPRESSION  CONTROL  DECK.  The  source  of  this  data  is  the  MAFIA  V Data 
Base  and  TRW  Engineering  Estimates. 

CONTROL  MEASURE  INPUT  DECK.  Source  of  this  deck  was  the  GFP  Scenario 
Package,  and  later  modifications  of  this  package  by  the  user  at  Fort  Benning 
during  the  evaluation  phase. 
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MINE  OBSTACLE  FORTIFICATION  INPUT  DECK.  The  source  of  this  data  was 
the  GFP  Scenario  Package  and  modifications  made  by  the  user  during  the 
evaluation  phase  at  Fort  Benning. 

ROAD  INPUT  DECK.  The  source  of  this  data  is  the  Terrain  Analysis  in 
Support  of  CATTS  by  the  Defense  Mapping  Agency  Topographical  Center. 

BRIDGE  INPUT  DECK.  The  source  of  this  data  is  TRW  Engineering  Estimates 

PREPLANNED  MISSION  INPUT  DECK.  The  source  of  this  data  was  letters  of 
changes  to  be  made  dated  17  June  1975;  18  June,  19  June,  CATTS  Directorate, 
Fort  Benning,  and  also  user  input  during  the  evaluation  phase  at  Fort  Benning 

MISCELLANEOUS  DECK.  This  deck  contains  solely  bookkeeping  type  numbers. 

NAME  LIST  DECK.  Name  list  data  at  the  end  of  the  data  base  consists 
primarily  of  bookkeeping  type  values  and  debug  control  printout  (see  Appen- 
dix B of  the  Data  Base/Operations  Manual).  However,  EQOVRD  and  some  of  the 
other  variables  that  relate  to  the  obstacle  model  came  from  the  user  during 
the  evaluation  phase  at  Fort  Benning,  SIAF,  Planning  and  Design  of  Roads,  Air 
Bases  and  Heliports  in  the  Theater  of  Operation,  TM  5-330,  and  Terrain  Analy- 
sis in  Support  of  CATTS  by  the  Defense  Mapping  Agency  Topographical  Center. 

The  source  of  all  the  data  on  the  terrain  relief,  vegetation,  and  soil 
files  in  the  CATTS  data  base  (RELIEF,  ELVDISP,  VEGCOMP,  VEGLOC,  and  SOIL) 
was  the  Terrain  Analysis  in  Support  of  CATTS  by  the  Defense  Mapping  Agency 
Topographical  Center. 

The  data  on  the  prescheduled  events  file  is  constantly  being  changed 
by  the  user  to  fit  the  different  scenarios. 


5. 7. 1.3  Equations 


Obviously  there  are  not  a large  number  of  equations  associated  with 
inputing  data. 

1)  The  direction  a unit  or  op  group  faces  is  input  as  a cartesian 
angle 

90 


180 

-180 


0 


-90 

and  the  following  formula  is  used  to  convert  this  value  to 
sine  and  cosine  which  are  used  in  the  model. 

S = S I N ( D I R • 0.0174533) 

C = C0S(DIR  • 0.0174533) 

where 


S is  the  sine  of  the  angle. 

C is  the  cosine  of  the  angle. 

SIN  & COS  are  functions  from  the  Xerox 
extended  FORTRAN  library  that  return 
the  sine  or  cosine,  respectively  of  any 
number  they  are  given. 

DIR  is  the  input  direction  the  unit  is 
to  face  in  degrees  in  the  cartesian 
coordinate  system. 

2)  The  basic  load  of  gasoline  (BLGAS)  and  diesel  fuel  (BLDIES)  are 

calculated  using  data  from  the  equipment  deck  and  unit  deck, 
NETU 

BLGAS  = X GCAPAC  • EQINIT 
1 


NETU 

BLDIES  = X DCAPAC  • EQINIT 
1 


where 
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NETU  is  the  number  of  different 
equipment  types  in  a unit  (1-14). 

EQINIT  is  the  amount  of  each  of  the 
one  to  NETU  types  in  a unit. 

GCAPAC  is  the  gasoline  capacity  for 
each  of  the  one  to  NETU  equipments 
in  a unit  in  gallons. 

DCAPAC  is  the  diesel  capacity  for 
each  of  the  one  to  NETU  equipments 
in  a unit  in  gallons. 

3)  The  input  days,  hours,  and  minutes  are  converted  to  a standard 
time  in  minutes  (JTIMEO)  since  midnight  on  day  zero. 

JTIMEO  = 1440  • NDAYE  + 60  • NHOURE  + NMINE 
where 

NDAYE  is  the  calendar  day  of  the 
start  of  the  simulation. 

NHOURE  is  the  number  of  hours  since 
midnight  at  the  start  of  the  simu- 
lation. 

NMINE  is  the  number  of  minutes  into 
the  hour  at  the  start  of  the  simu- 
lation. 

4)  Minefields  are  input  as  line  segments  along  with  all  other 
obstacles  in  the  mine  obstacle  fortification  input  deck.  How- 
ever, during  initialization,  minefields  are  converted  to  rec- 
tangles for  use  in  the  model  in  subroutine  MINEFLDS.  This 
subroutine  takes  the  input  endpoints'  coordinates  (OBX,  OBY, 

0BX1  & 0BY1 ) of  the  input  line  segment  and  calculates  the  four  pairs 
of  X, Y coordinates  (MINEX1,  MINEY1 , MINEX2,  MINEY2,  MINEX3,  MINEY3, 
MINEX4,  MINEY4)  of  the  corners  of  the  rectangle,  which  are  used 
by  the  obstacle  model  when  the  model  is  running.  This  conver- 
sion uses  the  following  formulas. 


SLOPE  = (0BY1  - OBY ) / ( OBX 1 - OBX) 
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where 

SLOPE  is  the  slope  of  the  input 
line  segment. 

PERPEND  = -1/SLOPE 

where 


PERPEND  is  the  slope  of  a line 
perpendicular  to  the  input  line 
segment. 

C = OBV  - PERPEND  • OBX 
Cl  = 0BV1  - PERPEND  . OBXl 
where 

C and  Cl  are  the  intercepts  of  the  lines 
perpendicular  to  the  input  line  segment, 
passing  through  each  endpoint  of  the 
input  line  segment.  These  equations  are 
the  slope  intercept  form  of  an  equation 
for  a straight  line. 

COSEC  A = ±(C0T2A  + 1)^2  Note:  input  line  segments 

are  processed  so  that 

COT  A = 1/TAN  A COSEC  A is  always  positive 

where  the  above  2 formulas  are  standard  trigonometric 
relations.  Combining  these  2 formulas  with  the  fact 
that  the  slope  of  a line  equals  the  tangent,  we  get: 

COSEC  A = ( 1 / ( TAN  A)2  + 1)1/2 

COSEC  A = ( 1 / ( PERPEND) 2 + 1 )1/2 

Next,  the  right-angle  triangle  trigonometric  function 

COSEC  A = h/a  yields,  a = h/COSEC  A 

where  a is  a side  of  the  triangle,  h is  the  hypotenuse 
of  the  triangle  and  A is  the  angle  opposite  side  a. 


a 


b 
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The  following  illustration  will  aid  in  under- 
standing the  final  calculations . 


Noting  that  in  this  case 
h = W/2 
where 

W is  the  input  width  of  the  obstacle  in 
meters . 

from  the  above  trigonometric  formulas  we  find 
a = ( 1 / (PERPEND)2  + 1 )1/2  • W/2 
and 

MINEY1  = OBY  + a 
MINEY?  = OBY  - a 
MINEY3  = 0BY1  + a 
MINEY4  = 0BY1  - a 

The  X's  are  then  calculated  using  the  Y values,  the 
previously  calculated  intercepts,  and  the  slope 
intercept  equation  of  a line. 

MINEX1  = (MINEY1  - C)/PERPEND 

MINE X2  = (MINEY2  - C)/PERPEND 

MINEX3  = (MINEY3  - C1)/PERPEND 

MINEX4  = (MINEY4  - C1)/PERPEND 


Page  5 


for  cases  where  the  input  line  segment  is 
vertical  and  the  slope  is  undefined,  the 
following  formulas  are  used: 

MINEY1  = OBY 

MINEY2  = 0BY1 

MINEY3  = MINEY1 

MINEY4  = MINEY2 

MINEX1  = OBX  - W/2 

MINEX2  = MINEX1 

MINEX3  = OBX  + W/2 

MINEX4  - MINEX3 

for  cases  where  the  input  line  segment  is  hori- 
zontal, and  the  slope  is  zero,  the  following 
formulas  are  used: 

MINEY1  = OBY  + W/2 

MINEY2  = OBY  - W/2 

MINEY3  = MINEY1 

MINEY4  = MINEY2 

MINEX1  = OBX 

MINEX2  = MINEX1 

MINEX3  = 0BX1 

MINEX4  = MINEX3 
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5.7.2  Alert  Message  Submodule 
5.7.2. 1 Operation 

The  Alert  Message  Submodule  generates  alert  messages  when  called 
upon  to  do  so  by  the  other  various  modules  of  the  math  model.  These  alerts 
are  then  passed  to  the  foreground,  which  can  then  display  them  on  the 
Super  Bee  terminals  for  the  instructors  to  read  and  process  (what  the  con- 
trollers may  do  with  alerts  at  the  Super  Bee  terminal  is  described  in  the 
CATTS  Operator's  Manual)  and  write  them  on  the  disk  to  be  saved  for  the 
alerts  post  processor  of  the  Alerts  Submodule.  However,  since  there  are 
no  routines  in  this  submodule  (ALERTGEN  and  ALNUALRT  are  part  of  the  fore- 
ground software)  Table  5-50  is  presented  for  completeness  rather  than  for 
information  content.  A complete  list  of  all  of  the  alerts  and  the  sub- 
routines where  these  alerts  are  generated  is  contained  in  Section  5. 7. 2. 3 
of  the  Programming  Report  and  Section  3.11  of  this  User's  Manual.  The 
alerts  cover  a wide  variety  of  situtations  including  beginning  and  ceasing 
fire,  receiving  fire,  detecting  enemy  units,  crossing  control  measures, 
firing  short  of  or  over  firing  control  measures,  damage  and  losses,  per- 
sonnel casualties,  fuel  and  ammunition  low,  obstacle  encounters,  resupply 
actions,  weather  changes,  and  simulation  control . 

There  are  two  methods  of  getting  an  alert  generated  in  the  math  model 

code . 

The  first  will  allow  the  user  to  generate  any  of  the  alerts  on  disk  in 
the  alert  library.  This  is  done  by  calling  subroutine  ALERTGEN.  A call  to 
ALERTGEN  would  appear  as  follows: 

CALL  ALERTGEN(NT,  NUNIT,  ITEM1 , NWl , 

ITEM2,  NW2, . . .,  ITEMK,  NWK) 

where 

NT  is  the  number  of  the  type  of  the 
alert  (1-120),  (see  Appendix  C of 
the  Programming  report  for  a complete 
list  of  types) . 

NUNIT  is  the  number  of  the  unit 
associated  with  the  alert.  Zero  is 
input  for  alerts  not  associated  with 
a unit.  This  controls  the  routing 
of  alerts.  (See  IUNIT  discussion). 


Table  5-50.  Alert  Message  Submodule  Subroutine  Descriptions 
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ITEM,  ITEM2,.  . . ITEM  K - These  are 
the  variable  parts  of  the  alerts,  and 
they  vary  in  number  (1-K)  and  con- 
tent depending  on  the  alert  type. 

They  include  things  like  unit  names, 
locations,  time,  etc.  They  are  speci- 
fied as  the  first  element  of  an  array, 
a scaler,  or  Hollerith  character  strings. 

NW1 , NW2,.  . . NWK  - is  the  number  of 
computer  words  associated  with  each  of 
the  same  numbered  items.  For  example, 
a 12  character  unit  name  occupies  3 
words  of  core. 

The  second  method  allows  the  user  to  generate  any  alert  desired.  The 
message  must  be  loaded  into  an  array,  and  then  subroutine  ALNUALRT  called. 
This  call  would  appear  as  follows: 

CALL  ALNUALRT(KNT,  IARRAY(l),  IROUTE) 
where 


KNT  is  the  number  of  computer  words 
that  contain  the  alert  (35  maximum). 

I ARRAY ( 1 ) is  the  first  element  of  the 
array  that  contains  the  alert. 

IROUTE  is  a number  between  1 and  7 
that  controls  which  consoles  the  alert 
will  be  sent  to: 


IROUTE  = 1 

console 

1 

2 

console 

2 

3 

console 

3 

4 

console 

1 & 3 

5 

console 

2 & 3 

6 

console 

1 & 2 

7 

console 

1,  2, 

Thus,  by  encoding  time,  unit  names,  or  whatever  is  desired,  any  message 
may  be  constructed  and  sent  to  any  of  the  controllers. 

New  alert  message  types  may  be  added  to  the  alert  library  by  running  pro- 
gram ALIBPROG  as  described  in  Section  4.4.15  of  the  Programming  Report  and 
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Appendix  B of  the  Data  Base/Operations  Manual.  Once  a new  type  is  added, 
ALERTGFN  can  be  called  by  the  appropriate  subroutine  to  send  the  new  type  to 
the  controllers. 

Any  alphanumeric  message  can  be  sent  to  the  controllers  at  any  model 
time  by  using  the  prescheduled  events  file.  To  do  this,  an  event  type  5 
should  be  punched  on  cards  and  added  to  the  prescheduled  events  f i 1 e^ . Word 
1 ( I VDT ( 1 ) ) should  be  equal  to  5,  word  2 ( I VDT ( 2 ) ) should  be  the  routing  as 
follows: 


I VDT (2)  VALUE 
1 
2 

3 

4 

5 

6 
7 


ROUTE  TO  CONSOLE  # 
1 
2 
3 

1 & 3 

2 & 3 
1 & 2 

1,  2,  & 3 


and  words  3 through  37  should  contain  the  message.  Note  that  since  the 
event  must  be  in  namelist  form,  the  alphanumeric  message  must  be  converted 
to  integer  numbers  to  be  input.  This  can  be  done  easily  by  a program  which 
reads  in  the  message  in  alphanumeric  format  and  writes  it  out  using  integer 
format.  Such  a program  (called  A2I  and  stored  in  the  Data  Base  card  file) 
was  used  by  the  field  service  personnel  to  punch  up  the  alerts  that  generate 
the  messages  which  identify  the  various  scenarios.  Shown  below  is  a sample 
of  how  the  message  identifying  scenario  FEBA  GOLD  appears  after  being  punched 
on  cards,  and  copied  to  the  prescheduled  events  file. 


NEVTP=  2, 

ITMEVE=  0, 

I VDT=  5 ,7  ,-472259008  ,-488054045  ,-975904192  ,-942024988  ,-680836927  , 
1088866518  ,-741087168  ,-689515067  ,-1002380572  ,-1025324604  , 
-910042648  ,1087817280  ,-472259008  ,-908737717  ,1799411673  , 

-974993963  ,-471703488  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  , 

0 ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  , 

0 ,0  ,0  ,0  ,0  ,0  ,1  , 


1 


See  Problem  Report  number  335. 
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* 


ITMEVE=  0, 

I VDT=5  ,7  ,-1052712221  ,-690362304  ,-691650349  ,-689584789  , 
'086440677  ,-975838236  ,-641373376  ,-1042955200  ,-473572903  , 
909978683  ,1088864729  ,455144000  ,1549556800  ,-960118079  , 

1 '86838483  ,-1002415012  ,1547714624  ,356532288  ,0  ,0  ,0  ,0  ,0  ,0  ,0  , 

0 ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  , 

,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,0  ,1  , 


Variables  IUNIT ( 1 00)  and  IWEATHER  control  the  routing  of  the  alert 
messages  for  all  alerts  associated  with  a unit  number  (1-100)  and  weathei 
alerts,  respectively.  The  values  of  IUNIT  and  IWEATHER  will  cause  an  alert 
associated  with  a particular  unit,  or  a weather  alert,  to  go  to  the  console 
using  the  standard  scheme  as  follows: 

Value  Console  Alert  is  Sent  to 


1 

2 

3 

4 

5 

6 
7 


1 

2 

3 

1 & 3 

2 & 3 
1 & 2 

1,  2,  & 3 


Variable  MH0WSEND(30)  controls  the  sending  of  alerts  to  Super  Bees 
and  the  saving  of  alerts  for  the  alerts  post  processor.  Each  of  the  120 
bytes  (30  X 4)  corresponds  to  an  alert  type  (1st  byte  to  alert  type  1,  2nd 
byte  to  type  2,  etc.),  and  the  value  of  the  byte  determines  what  happens 
to  that  alert  type  every  time  the  math  model  calls  the  alerts  submodule  to 
send  a particular  alert  type.  The  values  and  results  are  as  follows: 


Value  of  MH0WSEND  byte  Action  on  the  Alert 

0 Send  to  Super  Bees  and 

write  on  post-processor 

file. 

1 Write  on  post-processor 

file,  but  send  to  Super 
Bee  only  after  1st  minute 
of  game. 
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2 Write  on  post-processor 

file.  Don't  send  to  Super 
Bee. 

3 Don't  send  and  don't  write 

on  post-processor  file. 

Thus,  MHOWSEND  allows  selective  control  of  each  alert  by  type.  Note 
that  alerts  generated  by  calling  ALNUALRT  are  always  sent  to  the  Super  Bees 
and  always  written  to  the  post-processor  file  (these  alerts  are  automatic- 
ally assigned  a type  number  of  1000).  MHOWSEND  can  be  namelisted  in  the 
namelist  portion  of  the  math  model  run  deck  (See  Appendix  A of  the  Data 
Base/Operations  Manual)  if  the  user  desires  to  temporarily  turn  on  or  off 
an  alert  for  testing  purposes.  (Normally,  value  is  set  in  data  statements 
in  subroutine  FORMAIN).  Of  course,  care  must  be  exercised  in  setting  the 
value  of  a particular  byte,  since  the  smallest  unit  Xerox  allows  to  be 
namelisted  is  1 word  (4  bytes). 

Another  variable,  MTYP0FCM(35)  controls  alerts  due  to  control  measure 
crossings.  Each  of  the  140  bytes  of  this  array  corresponds  to  a control 
measure  type  (1st  byte  to  type  1 - assault  line,  2nd  byte  to  type  2 - fire 
coordination  line,  etc.)  and  the  number  in  the  byte  controls  the  alerts. 
Also,  the  MTYPOFCM  array  is  part  of  a scheme  that  stores  the  alphanumeric 
names  of  the  control  measures  in  a minimal  amount  of  core.  The  legal 
values  for  this  array  will  illustrate  both: 

VALUE  IN  MTYPOFCM  MEANING 

0 Don't  check  for  crossing  of  control 

measure  by  either  fire  or  units. 

Thus,  no  alert  will  be  generated 
for  this  type  of  control  measure. 
Obviously,  not  checking  saves  run- 
ning time  as  opposed  to  merely 
throwing  an  alert  away  after  it  has 
been  generated. 

1 to  40  Means  an  alert  of  type  M will  be 

generated  whenever  a unit  that  it 
applies  to  crosses  it.  Type  M 
refers  to  the  control  measure  types 
as  they  are  in  array  NAFtCM.  For 
example,  for  control  measure  type 
#3  - line  of  contact  - byte  3 of 
MTYPOFCM  contains  10,  and  the  10th 
name  in  NAME CM  is  "CONTACT".  How 
the  "LINE"  gets  added  is  discussed 
below. 
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Means  generate  alert  type  M as 
arranged  in  NAMECM  (the  64  is  sub- 
tracted to  get  M)  whenever  a unit 
to  which  the  control  measure  applies 
fires  support  fire  weapons  across 
the  control  measure. 

Means  generate  alert  type  M as 
arranged  in  NAMECM  (the  128  is  sub- 
tracted to  get  M)  whenever  a unit  to 
which  the  control  measure 
applies  fires  support  weapons 
short  of  the  control  measure. 

Array  MTYPOFCM  accomplishes  the  above  control  indirectly  by  loading 
the  right-most  byte  of  the  first  word  of  each  control  measure  when  the 
control  measure  is  created  (in  subroutine  CONTMS).  When  a control  measure 


is  created  interactively  or  from  the  data  base,  the  information  originally 


put  in  for 
measure  is 

the  right-most  byte 
converted  as  shown 

(byte  3)  of  the 
below: 

first  word 

of  each  control 

IN PUT  VALUE 

MEANING 

CONVERTED 

TO 

MEANING 

0 

Do  generate 
alerts 

By  subroutine 
CONTMS  using 
MTYPOFCM 

1-168 

Do  generate  alerts, 
as  shown  above 

non-zero 
(9  normally 
used  on  data 
base) 

Don't  generate 
alerts 

By  subroutine 
CONTMS 

0 

Don't  generate 
alerts,  this  type 
of  control  measure 
for  display  only 

Array  MTYPOFCM  can  be  namelisted  in  the  run  deck  (See  Appendix  A of  the 
Data  Base/Operations  Manual),  just  as  MHOWSEND  can,  but  both  are  normally  set 
using  the  data  statements  in  subroutine  FORMAIN.  Array  ICMBREAK(6)  and 
LABELCM(6)  add  the  "LINE",  "AREA",  etc.  to  the  alert.  Each  of  the  6 positions 
in  ICMBREAK  determine  which  of  the  6 four  letter  labjls  will  be  included  with 
the  name  (NAMECM)  of  the  control  measures.  The  current  values  of  ICMBREAK 
from  the  data  statement  in  subroutine  FORMAIN  of  8,  T8,  25,  29,  31 , & 33  mean 
that  the  first  8 types  listed  (1-8)  in  NAMECM  shall  receive  no  additional 
label,  8 to  17  will  receive  the  1st  label  from  LABELCM  of  "LINE",  18  to  24 
will  be  labeled  "AREA",  25-28  will  be  labeled  "ZONE",  29  to  30  will  be  labeled 
"POSN",  31  to  32  will  be  labeled  "BASE",  and  greater  than  32  will  be  labeled 
"PNT".  Thus,  new  types  of  control  measures  can  be  added  to  CATTS  by  merely 


(I  to  40)  + 64 


(1  to  40)  + 128 
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changing  a number  of  data  statements.  Note  that  there  are  data  statements  in 
the  foreground  code  that  must  also  be  changed  so  that  the  new  type  would 
appear  on  the  control  measure  menus. 

A totally  separate  part  of  the  alerts  submodule  is  the  alerts  post- 
processor. This  operates  basically  in  the  following  manner:  the  alerts  are 

saved  during  the  game  on  a file  (variable  MHOWSEND,  if  desired,  can  cause  some 
alert  types  to  not  be  saved),  and  after  a game  has  been  terminated  the  operator 
can  then  run  the  alerts  post-processor  program  PRALtRTS  (See  Appendix  B of  the 
Data  Base/Operations  Manual  for  SOP  #7,  Terminate  Game),  and  PRALERTS  will 
sort  and  print  the  alerts  for  post-game  analysis,  critique,  or  as  a permanent 
record  of  a game.  The  way  that  the  alerts  are  sorted,  and  which  alerts  appear 
in  which  reports  is  very  flexible,  and  is  controlled  by  the  card  image  file 
ANAMLIST.  A report  is  a collection  of  alert  types,  sorted  by  time  and  unit. 
Following  is  a discussion  of  which  variables  control  the  reports,  and  how  the 
alerts  to  be  included  in  each  report  are  controlled. 


Report/ Case  - One  report  is  generated  for  each  data  case  (data  cases  are  on 
file  DB,  ANAMLIST  in  card  image).  Data  cases  may  be  stacked 
back  to  back  in  order  to  generate  multiple  reports.  (There 
are  4 data  cases  in  the  sample  shown). 


Report  Controls 


Definition  of  alerts  to  be  included  in  report 

The  alerts  to  be  included  in  each  report  are  controlled  by  the  following 
variables: 

IACAT  (120,4)  - category  array 

IACAT(I,  J)  = 1 says  to  include  alert  number  I in 
category  J. 

IACAT ( I , J)  = 0 excludes  alert  number  I from  category  J. 

IWANT  (4)  - defines  category/categories  to  be  included  in  this  report. 

IWANT(J)  = 1 says  to  include  category  J in  this  report. 

IWANT(J)  = 0 excludes  category  J from  this  report. 

Thus,  for  example,  IWANT  = 1,  0,  0,  1 says  to  include 
in  this  report  all  alerts  in  categories  1 and  4 as 
defined  by  the  IACAT  array. 

IWANTS  - flag  to  include  or  exclude  special  alerts  (those  alerts 

with  alert  number  greater  than  120)  from  this  report. 

IWANTS  = 1,  include  in  report 

IWANTS  = 0,  exclude  from  report 
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Title  to  be  printed  on  top  of  each  page  of  report 

ITITLE  (20)  - 80  characters.  Nominal i zed  to:  ALERTS  SORTED  BY  UNIT 

Names  to  be  used  for  alerts  which  do  not  have  units  associated  with  them 

NAMEW  (3)  - 12  characters.  Name  associated  with  weather  alert. 

In  Data  statement,  nominalized  to:  WEATHER  REP. 

NAMEU  (3)  - 12  characters.  Name  associated  with  unattended  ground 

sensors  alert.  In  Data  statement,  nominalized  to: 

GROUND  SENS. 

NAMiS  (3)  - 12  characters.  Name  associated  with  special  alerts 

(those  alerts  with  alert  number  greater  than  120). 

In  Data  statement,  nominalized  to:  SPECIAL  REP. 

Number  of  lines  per  print  page 

NLPAGE  - In  Data  statement,  nominalized  to  38. 

Print  order  of  alerts 

For  print  purpose  , there  are  four  types  of  alerts: 

1)  alert  having  unit  name  associated  with  it 

2)  weather  alert 

3)  unattended  ground  sensors  alert 

4)  special  alert  (alert  number  greater  than  120) 

Each  of  these  types  has  a sort  priority  assigned  to  it,  which  is  used 
to  make  up  the  sort  key.  They  are  (with  nominal  values  in  parentheses). 

IPRNAME  ( 0)  names 

IPRWEAT  (500)  weather 
IPRUNAT  (501)  ground  sensors 
IPRSPEC  (502)  special 

The  sort  key  priority  for  each  named  alert  is  computed  as  KEYX  = IPRNAME  + N 
where  N is  the  table  lookup  index  (i.e.,  Nth  name).  The  nominal  values  couse 
the  alerts  to  sort  in  the  order:  named,  weather,  ground  sensors,  and  special. 
By  changing  the  priority  numbers,  the  user  can  change  the  sort  order  of  the 
four  types  of  alerts.  Since  there  are  up  to  150  named  units,  the  priority 
assigned  to  any  alert  type  which  is  to  follow  the  named  alerts  should  be  a 
value  at  least  151  greater  than  IPRNAME. 

Processing  associated  with  certain  alert  types 

1)  Weather  alert.  When  alert  type  IANWEAT  (nominalized  in  Data  state- 
ment to  35)  is  encountered,  priority  IPRWEAT  and  name  NAMEW  (3)  are 
associated  with  it.  The  user  can  cause  this  alert  type  to  be  treated 
like  a named  alert  (name  obtained  from  first  item;  up  to  12  charac- 
ters) by  setting  IANWEAT  = 0. 

2)  Unattended  ground  sensors  alert.  When  alert  type  IANUNAT  (nomina- 
lized in  Data  statement  to  64)  is  encountered,  priority  IPRUNAT  and 
name  NAMEU  (3)  are  associated  with  it.  The  user  can  cause  this  alert 
type  to  be  handled  like  a named  alert  by  setting  IANUNAT  = 0. 
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3)  Alert  type  IANTERM  (non  nalized  in  Data  statement  to  120)  acts  as  an 
end-of-file.  The  user  can  force  the  program  to  keep  reading  until  a 
zero  alert  type  is  found  by  setting  IANTERM  = 0. 

Non-standard  alerts 

Non-standard  alert  numbers  are  defined  by  the  array  NSFLAG(120).  This 
array  is  set  up  by  subroutine  NSALERT  which  reads  FORTRAN  unit  F:12.  The 
user  may  override  entries  in  NSFLA6  through  the  NAMELIST  input. 

NSFLAG(I)  = 0,  declares  alert  I to  be  standard 

= -1,  declares  alert  I to  be  non-standard,  and  indicates  that 
time  item  number  must  be  looked  up  in  alert  text  library. 
= N (positive),  declares  alert  I to  be  non-standard,  and 
indicates  that  Nth  item  of  alert  message  of  this  type  is 
time  item. 

Desired  order  of  unit  names 

The  order  that  unit  names  are  to  be  sorted  in  is  defined  by  the  array 
NAMEUN  (3,  NNAMES)  where  NNAMES  *=150.  This  array  is  set  up  by  subroutine 
ORDERUN  which  reads  FORTRAN  unit  11.  The  user  may  override  this  information 
by  entering  a list  of  names  in  the  desired  order  through  TEXTINP  input  (see 
further  on).  The  program  will  run,  with  the  names  sorted  on  a first  in/ 
first  out  basis,  with  no  list  of  names,  that  is,  with  NNAMES  = 0.  This  means 
the  order  the  alerts  appear  on  the  reports  will  be  constructed  from  the  order 
that  the  reports  are  on  the  post-processor  file,  and  once  this  order  is  con- 
structed it  will  be  used  for  the  remainder  of  the  reports. 

Last  case  indicator 

ITERM  = 0,  there  is  another  case 

= 1,  stop  after  finishing  this  case 

Files  referenced  (F:  # - see  RBM  Reference  Manual  on  ASSIGN  statements) 

1 05  - card  reader 
lDrf  - printer 

10  - input  alert  messages 

11  - desired  order  unit  names 

12  - non-standard  alert  types 
17  - alert  text  library 

fase  Data 

Subroutine  NSALERT  which  sets  up  the  non-standard  alert  numbers,  and 
subroutine  ORDERUN  which  sets  up  the  desired  order  of  unit  names  are  called 
only  before  the  first  case.  Also,  all  nominal  values,  as  discussed  in 
section  II,  are  not  reset  before  multiple  cases.  Thus,  any  values  that  are 
changed  by  the  user  through  input,  remain  changed  through  multiple  cases. 

Each  case  of  input  consists  of  tw ' types  of  data: 

1)  Hollerith  input  processed  by  ubroutine  TEXTDVF  and  referenced  as 
TEXTINP. 

2)  Numeric  data,  read  in  by  NAMELIST. 
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TEXTINP  data 

Card  is  broken  into  three  fields: 

a)  Col.  1-10,  variable  name  and  optional  subscript.  Variable  name 

must  precede  subscript  and  there  must  be  at  least  one  blank  between 
the  name  and  the  subscript.  The  name  does  not  have  to  be  left 
justified.  For  example:  IACAT  2. 

A continuation  of  data  from  the  previous  line  is  indicated  by 
leaving  col.  1-10  blank.  The  absence  of  a subscript  defaults 
to  a subscript  of  1 . 

b)  Col.  11-70,  data  field.  Format  depends  on  variable  being  entered. 

c)  Col.  71-80,  comments.  Ignored. 


Data  enterable  through  TEXTINP 

All  variable  entries  are  optional  and  may  be  entered  in  any  order  except 
for  the  end-of-data  terminator  END  which  must  be  entered  and  which  must  be 
last. 


a) 


Category  array,  IACAT 

This  array  may  be  set  up  through  NAMELIST,  but  it  is  easier  to  do 
it  through  TEXTINP. 


Input  format 

1 11  70 


IACAT  i 

include/exclude  designations  for  alerts  1-60 

include/exclude  designations  for  alerts  60-120 

card 


next  card 


i = alert  report  category  number  1,  2,  3,  or  4 


A non-blank  character  in  a column,  indicates  that  the  corresponding 
alert  number  is  to  be  included  in  category  (i);  a blank  excludes  the 
alert. 


The  data  must  be  entered  separately  for  each  category.  Thus,  the 
data  for  each  category  must  be  explicitly  preceded  by  IACAT  i. 

The  program  is  set  up  to  accept  IANMAX  entries  for  each  category, 
so  in  the  future  if  IANMAX  is  changed  to  a number  larger  than  120, 
the  processor  will  still  function  properly. 

b)  Report  title  array  ITITLE 
Input  format 


1 

1 

70 

ITITLE 

first  60  characters 

L 

3D 

last  20  characters 

1 


The  continuation  line  may  be  omitted,  but  then  the  last  20  characters 
will  remain  whatever  they  were  before. 
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The  first  20  characters  of  the  nominal  ITITLE  are  blank,  so  if  the 
title  is  not  long,  the  user  can  enter: 


1 


11 


70 


ITITLE  6 


last  60  characters,  first  20  left  as  they  were 


c)  Names  to  be  printed  on  report  for: 
weather  alert  - NAMEW 
unattended  ground  sensor  alert  - NAMEU 
special  alert  (alert  number  greater  than  120)  - NAMES 

Input  format 

1 11  22 

NAMEW  j weather  alert 

name 

. 1 _ 


NAMEU  | 

ground  sensor 

alert  name 

NAMES 

special  alert 

name 

d)  Unit  names  desired  order  array,  NAMEUN 
Input  format 


1 

NAMEUN 


11  22  31  4 

■2  51 

i 

12  characterl 
unit  name 

m 

12  character 
unit  name 

m 

62 

12  character 
unit  name 


Any  12  character  data  field  that  is  all  blank  is  ignored.  If  these 
entries  extend  the  length  of  NAMEUN,  the  length  NNAMES  is  automati- 
cally updated. 

Example: 


nameun  121 


1 AAAAAAAAAAAA 


B8RBBBBBBBBB 


CCCCCCCCCCCC 


Result  NAMEUN  (1, 
NAMEUN  (1, 
NAMEUN  (1, 
NAMEUN  (1, 


121)  = AAAAAAAAAAAA 

122)  = BBBBBBBBBBBB 

123)  = CCCCCCCCCCCC 

124)  = DDDDDDDDDDDD 


DDDDDDDDDDDD, 
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e)  End  of  Hollerith  data  terminator.  Must  be  entered  and  must  be  last. 
(That  is,  must  immediately  precede  the  NAMELIST  data.) 

Input  format 

1 11 

| END 


Data  enterable  through  NAMELIST 

The  main  program  contains  a NAMELIST  statement  with  no  parameters  so 
most  of  the  variables  in  the  program  r^ri  have  values  assigned  through 
NAMELIST  input.  The  only  parameters  normally  entered  are: 

a)  Category/categories  to  be  included  in  this  report  array,  IWANT 
IWANT  (I)  = 1,  include  category  I 

= 0,  exclude  category  I 

b)  Include/exclude(l/0)  special  alerts  (alert  numbers  greater  than 
120)  in  this  report  flag,  IWANTS. 

c)  Last  case  flag,  ITERM. 

Set  ITERM  = 1 in  last  case,  to  cause  program  to  terminate 

d)  Number  of  lines  per  report  page,  NLPAGE.  Set  in  first  case  to 
adjust  for  larger  paper. 

e)  Sort  priority  numbers  which  affect  order  that  different  types  of 
alerts  sort  in. 

IPRNAME  - named 
IPRWEAT  - weather 

IPRUNAT  - unattended  ground  sensors 
IPRSPEC  - special 
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SAMPLE  COPi  OF  FILE  DB,  ANAMLIST 


IACAT  1 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
END 

I WANT  = 1,  0,  0,  0, 

IWANTS  =1, 


ITITLE  6 ENGAGEMENT  ALERTS  SORTED  BY  TIME 

IACAT  2 XX  X XX  X X 

XXXX  XXXXXXX  X X XXXX 
END 

IWANT  = 0,  1,  0,  0, 

IWANTS  = 0, 

* 

ITITLE  6 LOSS  REPORT  ALERTS  SORTED  BY  TIME 

IACAT  3 X 

X X XX 

END 

IWANT  = 0,  0,  1,  0, 

* 

ITITLE  6 RESUPPLY  ACTIONS  ALERTS  SORTED  BY  UNIT 

IACAT  4 

XX 

END 

IWANT  = 0,  0,  0,  1, 

ITERM  = 1, 

★ 


XX  XXXX 
X 


XXX 

X 


X 


ENGAGE 
ENGAGE  2 


LOSS  1 
LOSS  2 


RESUP.  1 
RESUP.  2 


ALERT  Printout  Produced  by  Copy  of  File  DB  ANAMLIST  (Cont'd) 
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Sample  ALERT  Printout  Produced  by  Copy  of  File  DB  ANAMLIST  (Cont'd) 
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5. 7. 2. 2 Assumptions  and  Data  Sources 

The  obvious  assumption  inherent  in  this  submodule  is  that  useful  infor- 
mation can  be  conveyed  to  the  controllers  during  a game  using  the  alerts. 
This  has  proven  to  be  true  with  one  constraint:  volume.  If  there  are  too 

many  alerts  of  a given  type,  there  might  as  well  not  be  any  alerts  of  the 
type.  A good  example  is  the  visual  detection  alerts.  Sheer  volume  causes 
most  of  these  alerts  to  be  ignored  by  the  controllers,  and  when  a controller 
does  wish  to  know  if  one  unit  has  detected  another,  this  information  is  lost 
in  the  hundreds  of  detection  alerts. 

All  data  for  the  variables  which  control  the  alerts  was  provided  by  the 
Army  CATTS  project  personnel  at  Fort  Benning. 

5 . 7 . 2 . 3 Equations 

There  are  no  equations  inherent  to  this  submodule.  The  equations  which 
govern  the  alerts  are  covered  in  their  respective  write-ups. 


r 
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5.7.3  RAM  Alerts  Submodule 
5. 7. 3.1  Operation 

RAM  alerts  are  generated  in  the  various  modules  by  a call  to  subroutine 
RAMALERT.  This  causes  a message  to  be  sent  via  the  RAMTEK  to  the  lower  1/3 
of  the  selected  instructor's  TV  screen.  The  instructor  must  read  the  alert 
and  select  the  IGNORE  in  the  lower  right  hand  corner  of  the  alert  before  he 
can  use  the  menus  or  move  the  TV  camera  to  look  at  a different  portion  of  the 
map.  RAM  alerts  are  error  messages  or  instructions  resulting  from  simulation 
control  or  use  of  one  of  the  command  and  control  menus.  A complete,  though 
slightly  out  of  date,  list  of  all  RAM  alerts  is  contained  in  Section  5. 7. 3. 3 
of  tne  Programming  Report  and  Section  3.109  of  this  User's  Manual . These 
alerts  are  displayed  immediately  after  they  are  generated  on  the  TV  monitors. 
The  instructor  #,  the  number  of  characters  in  the  message,  and  the  name  of 
the  array  that  contains  the  message  or  the  array  name  including  indices  of 
the  first  element  of  the  array,  or  a Hollerith  character  string,  are  the 
arguments  in  a call  to  RAMALERT,  which  appears  as  shown  below: 

CALL  RAMALERT( INS#,  NUMBCHAR,  MESGARAY) 
where 

INS#  is  instructor  number 
(1,2,  or  3) 

NUMBCHAR  is  the  total  number  of 
characters  in  the  message. 

MESGARAY  is  the  name  of  the  array 
which  contains  the  message. 

Note  that  a colon  (:)  appearing  in  the  message  will  cause  the  characters 
after  it  to  appear  on  the  next  line  down  the  TV  screen,  but  the  colon  itself 
will  not  appear  on  the  screen.  Thus,  no  RAM  alert  message  should  contain  a 
colon  unless  a next  line  is  desired.  Also,  if  the  INS#  is  an  illegal  value 
(other  than  1,  2,  or  3)  the  message  will  appear  at  console  1 automatically. 
Table  5-51  gives  a brief  description  of  each  routine  in  this  submodule. 
However,  since  this  submodule  does  not  contain  any  subroutines  (RAMALERT 
is  part  of  the  foreground  software),  Table  5-51  is  presented  for  consistency 
and  completeness  rather  than  information  content. 
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5.7. 3.2  Assumptions  and  Data  Sources 

The  underlying  assumption  of  the  RAM  alerts  is  that  the  controllers 
should  be  informed  immediately,  in  a manner  they  can  not  miss  seeing,  of 
errors  made:  when  the  command  and  control  events  are  being  processed,  when 

the  model  is  being  initialized  (SAVE  files  not  found,  for  example),  and  of 
pertinent  instructions  or  errors  when  simulation  control  is  being  performed. 
The  only  potential  problem  with  RAM  alerts  would  be  the  generation  of  too 
many  RAM  alerts.  This  would  then  cause  the  controllers  to  be  so  busy  pro- 
cessing RAM  alerts  that  they  would  be  unable  to  use  the  console  to  input  com- 
mand and  control  or  move  the  camera.  Thus,  during  the  development  of  CATTS, 
every  effort  was  made  to  keep  the  number  of  RAM  alerts  to  a minimum,  while 
still  conveying  the  necessary  information  to  the  controllers. 

The  source  of  all  the  RAM  alerts  is  TRW  engineering  and  design. 

5.7. 3.3  Equations 

All  the  equations  which  generate  RAM  alerts  are  merely  checking  to  make 
sure  indices  to  arrays  have  not  been  exceeded,  legal  numbers  have  been 
received  from  the  foreground  for  a particular  portion  of  an  event,  or  that 
some  model  variable  has  been  set.  What  caused  the  RAM  alert  should  be 
obvious  from  the  explanation  in  Section  3.109  of  this  User's  Manual . 


w 


k 
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5.7.4  RATT  Submodule 

5. 7.4. 1 Operation 

This  submodule  allows  the  controllers  to  send  messages  from  the  Super 
Bee  terminals  to  the  simulated  RATT  teletype  (ASR-35)  in  the  TOC.  A con- 
troller may  edit  and  send  the  current  alert  message  on  the  Super  Bee  screen, 
may  edit  and  send  any  of  the  canned  RATT  messages  (up  to  100),  or  may  com- 
pose a new  message  and  send  it.  The  controller  may  also  "can",  or  save  on 
disk,  any  message  he  desires.  The  procedures  for  all  of  these  are  described 
in  detail  in  Section  2.7  of  the  CATTS  Operator's  Manual. 

The  players  may  type  any  message  they  wish  on  the  ASR-35  and  send  it  to 
the  controllers.  This  procedure  is  also  described  in  the  CATTS  Operator's 
Manual . Which  controllers  receive  the  messages  from  the  TOC  is  determined 
by  variable  I RATT,  which  can  be  set  in  either  the  namelist  portion  of  the 
data  base  scenario  file  (example-NBIG)  or  in  the  namelist  portion  of  the.  run 
deck.  This  variable  will  route  the  messages  as  shown: 

Value  Routing 

0 Ignore  - route  to  none  of  the  consoles 

1 Console  1 

2 Console  2 

3 Console  3 

4 Console  1 & 3 

5 Console  2 & 3 

6 Console  1 & 2 

7 Console  1 , 2,  & 3 

Also  of  interest  in  the  operation  of  the  RATT  is  program  RATTEDIT.  This 
program  allows  the  canned  RATT  messages  (i.e.,  saved  on  disk)  to  be  listed  on 
the  line  printer  (cataloged)  and  deleted.  This  program  is  explained  in  Appen- 
dix B of  the  Data  Base/Operations  Manual  and  Section  4.4.15.3.2  of  the  Pro- 
gramminq  Report. 

5. 7. 4. 2 Assumptions  and  Data  Sources 

The  RATT  submodule  was  designed  to  be  as  flexible  as  possible  since  the 
content  of  the  RATT  messages  and  the  use  of  the  RATT  system  are  bound  to  chanyt 
with  new  scenarios  and  changes  in  Standard  Operating  Procedures. 
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5. 7. 4. 3 Equations 

No  equations  are  applicable  to  this  submodule. 


this  submodule  is  in  the  foreground. 


All  the  code  that  runs 
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5.7.5  Status  Report  Submodule 
5. 7. 5.1  Operation 

The  Status  Report  Submodule  prints  the  Army  version  of  the  math  model 
status  report  (a  TRW  version  is  also  available  - see  Section  5.7.6,  Diag- 
nostic and  Miscellaneous  Output)  on  the  line  printer.  This  submodule  also 
outputs  on  the  line  printer  the  final  game  status  report,  which  is  part  of 
the  post  game  summary  (Section  5.7.6  covers  the  other  part). 

Figure  5-102  shows  the  subroutine  linkages  for  the  Status  Report 
Submodule  and  Table  5-52  gives  a brief  description  of  each  routine  as  well 
as  its  principal  inputs  and  outputs.  As  Figure  5-102  shows,  the  principal 
routine  of  the  submodule  is  STATREP1 . This  routine  is  not  called  (there- 
fore no  status  report  is  produced)  if  variable  IDOSTAT  is  zero.  If 
IDOSTAT  is  equal  to  a positive  number  N,  then  STATREP1  is  called  every  N 
model  minutes  and  again  at  the  end  of  the  exercise.  See  SOP  #7  in 
Appendix  B of  Data  Base/Operations  Manual. 

Once  STATREP1  is  called,  each  of  the  five  major  reports  it  produces 
is  separately  controlled  via  the  input  table  IOINTRVL.  Table  5-53  shows 
the  effect  of  possible  settings  upon  the  output.  Note  that  it  is  possible 
to  print  the  different  reports  at  different  intervals,  and  even  to  intermix 
TRW  and  Army  versions. 

The  status  report  format  is  the  same  for  both  the  periodic  and  final 
reports.  The  only  difference  is  that  the  change  in  levels  shown  are  since 
the  time  of  the  last  report  on  the  periodic  report,  but  on  the  final  the 
change  is  the  difference  from  the  start  of  the  game  to  the  end  of  the  game. 
There  are  five  basic  reports  or  parts  of  the  status  report  and  in  the  order 
printed  they  are:  Unit,  Equipment,  Ammunition,  Fuel,  and  Personnel.  A 

sample  of  the  first  page  of  each  of  these  reports  is  shown  on  the  next  page. 

All  the  items  on  the  reports  are  self-explanatory  with  the  possible 
exception  of  the  letters  which  appear  on  the  Unit  report  under  the  heading 
CCFLAGS.  The  letters  have  the  following  meaning: 

FLAG  MEANING 

M Unit  is  under  maneuver  command 

and  control  input  via  the  menus 
and  is  moving  mounted. 


Table  5-52.  Status  Report  Submodule  Subroutine  Descriptions 
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FUELLINE  Outputs  the  current  and  change  levels  of  fuel  for  Input:  None 

one  unit  and  saves  the  current  levels. 


Table  5-52.  Status  Report  Submodule  Subroutine  Descriptions  (Continued) 

Subroutine  Description  Principal  Inputs/Outputs 
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define  an  external  address  for  the  output  buffer. 

The  address,  8,  is  used  by  subroutine  PUT1  as  the  Output:  None 

beginning  of  in-core  buffer  address. 
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Table  5-53.  Controlling  the  Printing  of 
Status  Reports  Individually 


1 

REPORT 

CONTROLLING 

VARIABLE 

RESULT 

UNIT  STATUS 

10 I NTRVL ( 1 ) 

= 0 

Report  never  printed. 

EQUIPMENT 

I0INTRVL(2) 

= N > 0 

TRW  version  printed 
every  N mi nutes . 

AMMUNITION 

10 I NTRVL ( 3 ) 

(See  5.7.6) 

PERSONNEL 

I0INTRVL(4) 

= N<0 

Army  version  printed 
every  -N  minutes,  but 

FUEL 

10 1 NTRVL (13) 

only  if  IDOSTAT  set 
such  that  STATREP1 
called  every  -N  minutes. 
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D Unit  is  under  maneuver  command 

and  control  input  via  the  menus 
and  is  moving  dismounted. 

F Unit  is  under  fire  command  and 

control  input  via  the  menus. 

5. 7. 5. 2 Assumptions  and  Data  Sources 

The  obvious  assumption  here  is  that  a printed  record  of  the  status 
would  be  useful  to  the  controllers  both  during  and  after  a game. 

The  source  for  the  format  of  the  status  report  and  inclusion  or  exclu- 
sion of  various  numbers  was  a meeting  in  March  1976  at  Fort  Benning  between 
TRW  representatives;  Ed  Goldberg,  George  Wilde,  and  Bob  Milder,  and  the  Fort 
Benning  CATTS  Directorate  personnel  and  Naval  Training  Equipment  Center  repre 
sentati ves . 


5. 7. 5. 3 Equations 

None  applicable  to  this  submodule. 
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5.7.6  Diagnostic  and  Miscellaneous  Output  Submodule 
5. 7.6. 1 Operation 

There  are  other  printouts  available  from  the  math  model  in  addition  to 
the  Army  status  report.  Mostly,  these  are  printouts  used  during  development 
of  CATTS  to  debug  the  various  modules.  Some  of  this  debug  printout  might 
prove  useful  to  the  controllers,  and  all  of  it  would  certainly  be  useful  should 
problems  occur  or  for  debugging  future  changes.  All  of  the  debug  printout 
available  and  the  variables  which  turn  the  printouts  on  and  off  are  shown  in 
Appendix  B of  the  Data  Base/Operations  Manual.  The  TRW  status  report  is  one 
of  the  printouts  that  was  intended  for  controller  use.  It  contains  the  same 
information  as  the  Army  status  report  plus  some  information  that  is  more  pro- 
grammatical  than  tactical.  A sample  of  the  first  pages  of  each  of  the  5 sec- 
tions is  shown  on  the  next  page. 

Each  of  the  5 sections  corresponds  to  the  5 sections  of  the  Army  status 
report  (see  Section  5.7.5).  Each  of  the  5 sections  of  the  TRW  status  report 
can  be  individually  turned  on  every  N minutes  or  off  when  N = 0 by  namelisting 
IOINTRVL  of  1 , 2,  3,  4,  and  13  equal  to  N in  the  run  deck.  The  1,  2,  3,  4, 
and  13  correspond  to  unit,  equipment,  ammunition,  personnel,  and  fuel  reports, 
respectively.  The  default  in  the  namelist  portion  of  the  data  base  file  is 
zero  for  all  15  IOINTRVL  elements. 

The  other  printout  intended  for  controller  use  is  a casualty  report 
which  is  the  first  part  of  the  post  game  surrmary  (the  other  part  of  the  post 
game  summary  being  the  final  status  report).  This  casualty  report  shows,  for 
red  then  blue,  which  weapons  destroyed  which  enemy  equipment  and  personnel, 
and  the  amounts  each  weapon  destroyed.  This  report  is  always  produced  if  the 
game  is  normally  terminated  (SOP  #7  in  Appendix  B of  the  Data  Base/Operations 
Manual ) . 

The  diagnostic  output  is  scattered  throughout  the  other  modules  of 
CATTS.  The  only  readily  separable  portions  are  those  which  produce  the  TRW 
status  report  (STATREP)  and  the  casualty  report  (CASREP).  Subroutine  linkages 
for  these  are  shown  in  Figure  5-103,  while  Table  5-54  gives  a brief  description 
of  each  with  its  principal  inputs  and  outputs. 

Shown  on  the  last  pages  of  this  section  is  a sample  of  this  casualty  report 
(produced  by  subroutine  CASREP). 
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Figure  5-103.  Subroutine  Linkage  for  the  Diagnostic  Submodule 


Table  5-54.  Diagnostic  and  Miscellaneous  Output  Submodule  Subroutine  Descriptions 

Subroutine  Description  Principal  Inputs/Outputs 


Suppose  blue  equipment 
I kills  one  red  equip- 


ort  (Continued) 
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5. 7. 6. 2 Assumptions  and  Data  Sources 
None  applicable. 

5. 7. 6. 3 Equations 
None  appl icable. 
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S.G  AIR  MODULE 

Tue  GAITS  Air  Module  is  subordinate  to  the  ground  combat  models, 
its  sole  purpose  being  to  provide  greater  realism  to  the  ground  combat 
simulation.  Thus,  only  those  features  of  aircraft  and  air  missions, 
whicn  are  necessary  to  provide  a credible  interaction  with  ground  com- 
bat are  modeled.  Air  units  and  air  missions  exist  only  for  the  dura- 
tion of  the  mission.  Once  all  the  aircraft  in  a unit  are  lost,  or  the 
remaining  aircraft  complete  the  mission  successfully  and  land,  the  unit 
ceases  to  exist.  Ground  based  activities  and  support  requirements  for 
air  units  are  not  modeled. 

5.8.1  Operation 

Each  model  timestep,  the  CATTS  Air  Module  performs  all  calculations 
necessary  to  the  function  of  air  units  within  CATTS.  Location,  direction, 
speed,  and  fuel  consumption  of  air  units  is  updated.  All  air-ground 
interactions  are  calculated,  including  ground-t.o-ai r and  air-to-ground 
detections,  air  defense  fire,  the  delivery  of  air  weapons  against  ground 
'targets,  attrition  to  air  unit  from  air  defense,  damage  and  casualties  to 
roads,  bridges,  and  ground  units  from  air-delivered  weapons,  and  attri- 
tion to  air  units  resulting  from  support  fire  i nterference-whether  adver- 
tent or  inadvertent. 

CATTS  is  a time-step  model,  with  time-steps  normally  60  seconds 
long.  Ground-ground  interactions  occur  only  at  the  ends  of  time-step 
movement  cycles.  The  high  speed  of  modern  tactical  aircraft  makes  this 
time  step  too  long  to  be  practical  for  air  units,  since  a fast  aircraft 
can  cover  up  to  20  kilometers  in  a single  minute-long  time-step.  Cal- 
culating air-ground  interactions  only  for  points  60  seconds  air  travel 
time  distant  from  each  other  results  in  absurd  effects.  For  example,  an 
air  unit  would  frequently  be  out  of  range  of  air  defense  weapons  in  a 
ground  unit  even  though  it  overflew  the  unit  at  some  point  during  the  60 
seconds.  Thus,  the  high  speed  of  aircraft  relative  to  ground  units  dic- 
tated the  use  of  a shorter  time-step  for  the  air  units  in  order  to 
achieve  greater  tactical  realism.  A maximum  time-step  of  15  seconds  for 
air  units  was,  therefore,  called  out  in  the  CATTS  specification. 
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The  problem  of  integrating  a 15-second  time-step  air  model  and  a 
60-second  time-step  ground  model  was  solved  in  a fairly  simple  way 
which  yet  provides  great  flexibility.  For  each  ground  time-step,  at 
least  four  15-second  (or  less)  air  time-steps  are  calculated.  Loca- 
tions, speeds,  altitudes,  weather  effects,  and  fuel  consumption  are 
pre-cal culated  for  four  (or  more)  points  per  air  unit  during  each 
60-second  time-step.  Then,  during  the  next  60-second  time-step,  the 
air-ground  interactions  resulting  from  these  four  (or  more)  locations 
are  calculated.  Shortly  after  the  interaction  calculations,  four 
(or  more)  new  locations  are  calculated,  and  the  cycle  continues. 

Calculating  the  air  unit  locations  in  one  time-step  and  not  cal- 
culating interactions  until  the  next  time-step  seems  to  be  unnecessary 
coriipl  i cat  ion.  However,  terrain  effects  on  air  units,  which  are  not 
modeled  in  the  current  CATTS,  were  originally  intended  for  inclusion 
in  the  model.  Computer  storage  and  execution  speed  requirements  dic- 
tated that  all  terrain  effects  be  calculated  simultaneously. 

Since  the  terrain  effects  calculations  occur  "between"  math  model 
time-steps,  it  was  necessary  to  pre-cal cul ate  locations,  store  them 
for  access  by  the  terrain  model,  and  calculate  air-ground  interactions 
during  the  next  time-step,  after  terrain  effects  had  been  calculated. 

This  unfortunately  results  in  a situation  depicted  in  Figure  5-104, 
in  which  logically  speaking,  locations  are  calculated,  terrain  effects 
(could  be)  calculated,  and  then  air-ground  interactions  are  calculated; 
while  chronologically  speaking,  air-ground  interactions  (for  locations 
calculated  during  previous  time-step)  are  calculated,  then  new  loca- 
tions, and  then  terrain  effects  for  the  new  locations. 

One  more  fairly  straightforward  complication  for  air  module  pro- 
cessing results  from  the  fact  that  to  display  air  unit  locations  as 
they  are  calculated,  and  before  air-ground  interactions  are  calculated, 
can  result  in  misleading  and  incorrect  displays.  Air  defense  fire,  for 
example,  can  destroy  an  air  unit  at  some  point  during  the  time-step,  in 
which  case  it  might  never  reach  the  location  displayed.  For  this  reason, 
the  displays  of  air  units  reflect  the  locations  of  the  unit  during  the 
preceding  time-step,  for  which  air-ground  interactions  are  all  ady  known. 
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a.  Logical  Sequence  b.  Chrononlogical  Sequence 


**  No  terrain  effects  actually  calculated  in  present  model 
Figure  5-104.  Processing  Sequence  for  Air  Module 
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The  interactions  of  the  CATTS  air  module  with  the  other  CATTS  modules 
is  depicted  in  Figure  5-105.  Observe  that  the  only  communication  with  other 
modules  is  through  the  data  base,  except  for  calls  to  subroutines  GRNDAIR 
and  AIRGRND.  In  fact,  the  three  chains  of  the  air  module  represented  by 
AIREVENT,  AIRMOV,  and  AIRM0V2  communicate  with  each  other  only  through  the 
data  base. 

The  CATTS  air  movement  model  moves  airborne  air  units  by  discrete 
time  sub-steps  of  not  longer  than  15  seconds.  Each  air  unit  has  an  input 
flight  plan  which  specifies  its  route  as  a series  of  straight  line  segments 
(legs)  between  air  control  points  (ACPs)  as  depicted  in  Figure  5-106.  Asso- 
ciated with  each  leg  are  a desired  altitude  and  velocity.  The  unit's  alti- 
tude and  velocity  are  incremented  or  decremented  each  time  sub-step  by 
constant  amounts  (which  are  limited  by  aircraft  performance)  until  they 
reach  the  desired  values  for  the  current  flight  leg.  This  process  is 
depicted  in  Figures  5-107  and  5-108.  They  then  remain  constant  until  the 
next  control  point  is  reached,  at  which  time  the  process  of  velocity  and 
altitude  adjustment  begins  again.  At  the  end  of  each  time  sub-step,  local 
weather  conditions  are  assessed  for  the  feasibility  of  continuing  the 
mission.  Should  the  weather  be  sufficiently  unfavorable,  an  alert  message 
is  issued  and  the  air  mission  is  aborted. 

Each  time  sub-step,  subroutines  of  the  target  acquisition  model  are 
called  to  compute  air-to-ground  and  ground-to-air  detection  verdicts.  Each 
detection  results  in  an  alert  message.  It  also  allows  the  detecting  unit 
to  engage  the  detected  unit  if  engagement  is  consistent  with  the  detecting 
unit's  mission  and  within  the  capability  of  its  weapons.  If  an  engagement 
occurs,  the  damage  to  the  engaged  unit  is  determined  by  the  weapons  effects 
functions.  Engagement  of  a ground  unit  by  an  air  unit  may  force  engagement 
of  the  air  unit  by  the  ground  unit,  and  vice  versa. 

However,  air  units  will  not  fire  at  a ground  unit  other  than  an 
assigned  target.  The  controller  has  the  capability  using  the  interactive 
command  and  control  system,  of  changing  the  mission  of  a unit  while  it  is 
in  flight.  He  can  assign  a new  target,  for  example,  on  receipt  of  an  alert 
message  indicating  that  the  air  unit  has  detected  a ground  unit  which  is, 
for  some  reason,  an  attractive  target. 
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Figure  5-105.  Interactions  Between  Air  Module  and  Other  Modules 
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TAKEOFF 

LANDING 
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N ) = air  route  point  N 


Figure  5-106.  Sample  Air  Unit  Flight  Plan 


Page  5-750 


= Air  route  point 
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Figure  5-108.  Sample  Ground  Speed  Contour 


Page  5-751 


When  an  air  unit  reaches  the  last  point  on  its  flight  route,  the 
landing  point  (which  is  the  last  checkpoint,  IACPX,  IACPY),  a delay  time 
is  computed  to  model  the  delay  time  associated  with  the  landing  time  delay 
( I AMTE ( IU, 2) ) for  the  particular  type  of  aircraft.  When  the  delay  time 
has  elapsed,  the  air  unit  will  become  inactive.  Note  that  the  pre- 
sc heduling  feature  of  the  interactive  com  and  and  control  sub-system  makes 
it  possible  for  the  input  to  have  been  made  at  any  time  previous  to  its 
desired  execution. 

When  a new  air  mission  is  initiated,  that  mission  is  examined  to  see 
. t it  is  within  the  capabilities  of  the  aircraft.  Among  the  factors 
jnsidered  are  aircraft  range  (EQCAPAC( IEQ) ) and  gross  payload  ( ROME ( I EQ , 1 ) ) 
The  latter  is  a function  of  the  current  weather  conditions  including 
'emperature.  Unfeasible  conditions  result  in  an  alert  message  and  mission 
' ->'icel  lation.  A feasible  mission  is  initiated  after  appropriate  delays. 

The  Air  Module  is  designed  to  perform  three  general  functions  in  the 
CATTS  model,  and  within  those  three  general  functions,  a number  of  speci- 
fic functions.  First,  the  module  processes  the  air  event  notice  to  ensure 
that  no  requirements  in  the  event  notice  are  beyond  the  performance  capa- 
bilities of  the  aircraft  specified.  Second,  the  module  updates  the  loca- 
tion, direction,  and  speed  of  each  air  unit  each  time-step  at  subintervals 
of  1/4  minute  or  less.  Third,  the  module'computes  all  air-ground  inter- 
actions for  all  air  units  and  all  ground  units  at  each  subinterval  in  the 
time-step.  These  interactions  include  detection,  firing  and  casualty 
assessment. 

The  Air  Module  subroutine  linkages  are  illustrated  in  Figures  5-109, 
5-110,  and  5-111,  with  a brief  statement  describing  the  function  of  each 
subroutine.  There  are  three  distinct  chains  of  processing:  (1)  the 
AIREVENT  chain  for  air  event  notice  processing;  (2)  the  AIRMOV  chain  for 
air  unit  position  updating;  and  (3)  the  AIRM0V2  chain  for  ground-air 
interaction. 

The  Air  Module  is  called  at  two  different  points  during  the  execution 
of  the  mathematical  model  each  minute.  When  an  air  mission  is  created,  the 
ir  events  processor  is  called  to  process  the  event  notice  (see  Section 
5.8.1.;'.  At  its  conclusion,  it  has  stored  the  air  unit  data  in  appropriate 
"'non  blocks  for  use  by  the  remainder  of  the  Air  Module. 
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PPEVENT 


AIREVENT 

• Analyzes  air 
event  notice 
to  insure 
the  mission 
requirements 
do  not  con- 
flict with 
aircraft 
performance 
capabi 1 i ties 


• Initializes 
variables 
for  AIRMOV 
and  AIRM0V2 
chai ns 




PPEVENT 


AIRERROR 


• Formats  ERROR  MESSAGE  for  a RAMALERT 

(see  Section  5.7.3) 


RAMALERT 


BRRDCHCK 


• Determines  target  location  as  middle 
of  road  or  bridge  if  target  is  road 
or  bridge 


ALERTGEN 


(see  Section  5.7.2) 


ORDPRI 


Searches  through  ordnance  carried 
by  aircraft  and  picks  highest 
priority  ordnance  for  target 


AIRABORT 


• Determines  route  back  to  base  for 
an  aborted  air  mission 


SWITCH 


• Utility  routine 
to  reverse  entries 
in  an  array 


CLEARDET 


• Clears  ground-to-air  and  air-to-ground 
detection  arrays,  and  clears  ground-to- 
air  engagement  array 


Figure  5-109.  Air  Module  Subroutine  Linkage  for  AIREVENT  Chain 
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Figure  5-111 


Air  Module  Subroutine  Linkage  for  AIRM0V2  Chain 
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The  Air  Module  begins  with  a call  to  AIREVENT  by  PPEVENT,  the  primary 
EVENT  activator,  when  an  air  event  notice  has  been  created  by  a controller. 
The  remainder  of  the  Air  Module  chain  begins  with  a call  to  AIRM0V2  by 
FORMAIN,  the  main  mathematical  model  driver  program.  AIRM0V2  acts  as  a 
driver  for  the  majority  of  the  module  by  cycling  through  all  air  units  and 
ground  units  each  quarter  minute,  using  the  air  unit  positions  pre- 
calculated by  AIRMOV.  It  calls  subroutines  to  determine  ground-air  and 
air-ground  detections,  air  defense  fire  from  ground  units  against  air 
units  and  its  effect,  accomplishment  of  an  air  strike  against  a ground 
target  and  its  effect,  checks  for  control  measure  violations,  and  generates 
appropriate  alert  messages. 

When  an  air  unit  is  originally  created  and  processed  by  AIREVENT,  it 
generally  is  given  a non-zero  take-off  delay  ( I AMTE ( I AC , 1 ) ) . When  the 
take-off  delay  expires,  AIRM0V2  will  still  not  process  the  air  unit 
because  it  has  no  position  points  until  AIRMOV  executes.  Subsequently, 
AIRMOV  is  called  by  FORMAIN  near  the  end  of  a time-step.  It  computes  the 
air  unit's  position  for  the  entire  next  time-step,  at  quarter  minute  inter- 
vals or  less.  When  the  next  time-step  occurs,  AIRM0V2  will  process  pre- 
computed points.  The  cycle  is  repeated  until  the  air  unit  completes  its 
mission,  at  which  time  a landing  delay  is  applied  by  AIRMOV  and  the  air 
unit  is  henceforth  ignored  by  the  Air  Module,  except  that  it  is  kept 
active  for  display  during  the  landing  period.  At  the  completion  of  the 
landing  period,  the  air  unit  ceases  to  exist  and  is  removed  from  active 
status  by  AIRMOV. 

The  subroutines  are  described  individually  with  accompanying  flow 
charts  in  the  material  that  follows.  The  individual  write-ups  are 
grouped  according  to  the  linkage  chain  they  belong  to  and  their  sequence 
in  that  chain. 

5. 8. 1.1  AIREVENT  Chain 

AIREVENT  is  called  by  PPEVENT  whenever  a new  air  event  notice  is  to 
be  processed  during  the  current  time-step.  The  purpose  of  AIREVENT  is  to 
process  the  event  notice  so  that  the  proper  data  for  the  particular  mission 
desired  has  actually  been  included  by  the  controller  in  the  event  notice. 
(See  page  5- S50  fc  an  oxample  of  ar.  air  event  notice  (event  type  8)). 
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Once  that  determination  has  been  made,  and  also  the  determination  that  there 
are  no  conflicting  requirements  contained  within  the  event  notice,  all  the 
variables  required  by  AIRMOV  and  AIRM0V2  are  initialized  to  begin  the  air 
mission.  AIREVENT  does  essentially  the  same  checking  whether  the  event 
notice  is  for  a new  mission  or  a modification  of  the  old  mission.  If  the 
event  notice  is  a cancellation  notice,  then  AIREVENT  sets  the  appropriate 
variables,  generates  the  alert,  and  calls  AIRABORT  without  conducting  any 
checking. 

The  AIREVENT  chain  subroutine  linkage  is  shown  in  Figure  5-109.  Those 
subroutines  described  in  detail  in  other  sections  are  so  noted.  Table 
5-55  presents  a brief  description  of  each  subroutine  in  AIREVENT,  including 
the  principal  inputs  and  outputs.  See  Table  5-56  for  a listing  of  the 
error  messages  by  error  type. 

AIREVENT  begins  by  processing  the  second  word  of  the  event  notice 
( I NVCT ( 2 ) ) to  determine  the  general  type  of  the  event  notice  (i.e.,  new 
mission,  modify  old  mission  or  cancel  mission).  If  the  event  notice  is 
for  the  creation  of  a new  air  mission,  AIREVENT  next  analyzes  I NVDT ( 3 ) to 
determine  the  nature  of  the  mission  (red  or  blue,  strike  or  reconnaissance) , 
checks  to  see  if  there  are  any  air  units  available,  and  examines  INVDT(4) 
and  I NVDT ( 5 ) to  insure  a proper  equipment  type  and  number  of  equipments 
have  been  specified.  Using  aircraft  type,  AIREVENT  then  determines  if  the 
meteorological  visibility  (VI SM ) and  density  altitude  (DNSALT)  are  proper 
to  allow  continuance  of  the  mission.  If  any  of  these  tests  are  failed, 
AIREVENT  calls  AIRERROR  to  generate  a RAMALERT  for  the  instructor  and 
returns  to  the  calling  routine.  If  none  of  the  tests  are  failed,  personnel 
are  assigned  to  the  air  unit  and  AIREVENT  begins  its  next  portion  of  its 
analysis  of  the  event  notice. 

If  the  event  notice  was  to  modify  an  old  mission,  AIREVENT  does  some 
initial  checking  to  determine  the  status  of  the  old  mission.  If  the  old 
mission  is  still  active,  internal  variables  in  AIREVENT  are  set  from  :f 
contained  in  the  event  notice  and  the  unit  files  for  that  mission,  at 
code  branches  to  the  next  portion  of  the  event  notice  analysis.  If 
mission  is  no  longer  active,  the  mission  is  cancelled  with  a ca'  ’ 

ALERTGEN  to  generate  the  RAMALERT,  and  AIREVENT  returns  to  t' ■ 


Table  5-55  AIREVENT  Chain  Subroutine  Descriptions 
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Table  5-55.  AIREVENT  Chain  Subroutine  Descriptions  (Cont'd) 
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Table  5-55.  AIREVENT  Chain  Subroutine  Descriptions  (Cont'd) 


(in  pounds/minutej). 

Fuel  expenditure 
at  maximum  speed  • 
(in  pounds/minutej). 
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Table  5-55.  AIREVENT  Chain  Subroutine  Descriptions  (Cont'd) 
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AI REVENT  Chain  Subroutine  Descriptions  (Cont’ 
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INVDT(JEVT)  (See  subroutine  PPEVENT) 

I POADX ( I RDSG)  The  / coordinate  of  all  the 
input  roads.  Index  into 
array  for  road  N given  by 
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At  this  point,  the  two  threads  of  code  associated  with  a new  mission 
or  the  modification  of  an  old  mission  have  come  together  in  AIREVENT  for 
the  remainder  of  the  event  notice  analysis. 

AIREVENT  now  begins  the  processing  of  the  selected  route  to  determine 
any  incorrect  entries,  inconsistencies  or  requirements  for  performance 
beyond  the  capabilities  of  the  aircraft  selected.  AIREVENT  calls,  if  this 
is  a new  mission,  subroutine  CLEARDET  to  clear  all  the  detection  arrays 
indicating  detection  of  ground  unit  by  air  unit,  detection  of  air  unit  by 
ground  unit,  and  engagement  of  air  unit  by  ground  unit  air  defense  weapons. 
AIREVENT  then  checks  the  number  of  points  selected  on  the  route  of  flight 
to  insure  they  are  within  limits,  it  analyzes  the  target  selected  to  insure 
it  is  valid,  and  finally  determines  if  visibility  conditions  are  appropriate 
for  a strike  mission.  AIREVENT  also  checks  to  see  if  a guided  weapon 
(IEQCLS(IEQ)  = 10)  is  part  of  the  aircraft  weapons.  If  so,  it  assumes  that 
the  target  selected  is  the  target  of  the  guided  weapon,  and  does  the 
remainder  of  its  processing  based  on  that  premise. 

AIREVENT  ne'  ■;  b Tins  a point  by  point  analysis  of  the  route  during 
which  it  checks  each  leg  to  insure  that  altitude  and  speed  limitations 
are  not  exceeded  ( IV < R0ME( IAC,3) , IV  > R0ME( IAC,5), IZ  > ROME ( I AC , 2 ) ) . When 
it  checks  the  leg  of  the  route  containing  the  target,  if  the  target  is  a 
bridge  or  a road,  it  calls  BRRDCHCK  to  get  the  coordinates  of  the  mid-point 
of  the  road  or  bridge  to  use  as  the  target  point.  It  checks  to  insure  that 
fuel  expenditure  rates  are  not  less  than  minimum  assigned.  Then  AIREVENT 
conducts  an  analysis  of  the  selected  load  to  insure  that  it  is  less  than 
the  maximum  that  can  be  carried  (MAXLOAD)  and  that  there  is  enough  fuel  on 
board  to  fly  the  new  route  (if  this  is  a modification  of  an  old  mission). 
AIREVENT  then  examines  the  equipment  load  (ordnance  and/or  sensors)  to  insure 
they  are  compatible  with  the  aircraft,  and  that  the  aircraft  can  actually 
carry  the  total  weight  of  the  equipment. 

At  this  point  AIREVENT  checks  to  insure  that  there  is  ordnance  if  it 
is  a strike  mission,  and  that  the  ordnance  is  appropriate  for  the  target. 

It  calls  ORDPRI  to  pick,  from  the  ordnance  on  the  aircraft,  the  particular 
kind  of  ordnance  that  has  the  highest  priority  for  the  target  type. 
the  mission  is  a stand-off  strike,  but  there  are  no  guided  weapons  on  board, 
there  will  be  a ram-alert  generated  for  the  instructor  and  AIREVENT  will 
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return  to  the  calling  routine.  AIREVENT  then  checks  to  insure  that  the 
distance  between  the  stand-off  point  and  the  target  is  within  the  range  of 
the  guided  weapon  ( IMAXRE ( IBETA,1 ) ) . There  are  then  four  checks  against 
minimum  and  maximum  release  altitudes  and  speeds  for  the  weapon  selected 
(R0ME(IBETA,2)  to  R0ME( IBETA,5) ) . 

If  all  the  tests  are  passed  then  AIREVENT  initializes  variables  for 
AIRMOV,  AIRM0V2  and  the  foreground.  Most  of  the  variables  initialized 
are  contained  in  the  common  blocks  ROUTING,  MOVERATE,  BSTAT,  AIRLOC, 
AIROUTES,  BOBBY,  BLEFT1 , BLEFT2,  AVFUEL  and  FGAIRLOC . They  are  used 
throughout  AIRMOV  and  AIRM0V2  during  the  "flight"  of  the  air  mission. 

The  variables  initialized  in  common  block  FGAIRLOC  are  used  to  display 
the  route  of  flight  on  the  monitors. 

The  general  logic  flow  of  AIREVENT  is  illustrated  in  Figure  5-112. 
Brief  descriptions  of  the  subroutines  called  by  AIREVENT  follow. 

a.  AIRERROR 

AIRERROR  is  called  by  both  AIREVENT  and  BRRDCHCK  with  a subroutine 
argument  indicating  the  type  of  error.  It  formats  the  error  message  for 
the  particular  error  type  detected  by  the  calling  routines.  It  first  gets 
the  mission  name  (INVDT(6)  and  INVDT(7)  if  this  is  a new  mission, 

IUNNAME(1 , IU)  and  IUNNAME(2, IU)  if  this  is  a modification  or  cancellation) 
and  combines  it  with  the  error  message.  If  there  is  an  invalid  equipment 
type  (IERROR  = 5 or  6)  involved,  it  merges  the  equipment  type  into  the 
error  message.  It  then  calls  RAMALERT  to  send  the  message  to  the  appro- 
priate instructor  (INVDT(64)),  and  returns  to  the  calling  routine.  Table 
5-56  shows  the  various  error  messages.  The  general  logic  flow  of  AIRERROR 
is  illustrated  in  Figure  5-113. 

b.  RAMALERT 

See  Section  5.7.3  for  a description  of  RAMALERT. 

c.  BRRDCHCK 

BRRDCHCK  is  called  by  AIREVENT  when  the  designated  target  of  an 
air  mission  is  a bridge  or  a road.  The  purpose  of  BRRDCHCK  is  to  return 
the  center  of  a bridge  or  road  as  the  target  point  if  it  lies  within  1000 
meters  of  the  selected  target  point. 
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Check  route  for  proper 
# of  points,  check 
mission  for  valid 
target,  and  check 
visible  range 


/ Were  \ 
any  checks 
v failed?  ^ 


RETURN 


Check  each  point  on 
route.  If  this  is  a 
standoff  mission  flag 
target  point 


Call  BRRDCHCK  if  this 
is  a strike  mission. 
Check  altitude  and 
velocity  against 
limits 
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RETURN 


Calculate  fuel  re- 
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load  aircraft  can 
carry 


Figure  5-112.  General  Logic  Flow  of  AIREVENT,  Cont'd. 
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Figure  5-112.  General  Logic  Flow  of  AIREVENT,  Cont'd 
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Figure  5-112.  General  Logic  Flow  of  AIREVENT,  Cont'd 


Table  5-56.  Air  Error  Messages 


Table  5-56.  Air  Error  Messages  (Cont'd) 
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Figure  5-113.  General  Logic  Flow  of  AIRERROR 
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BRRDCHCK  begins  by  initializing  the  x-  and  y-values  of  the  test 
distance  ( ISAVEX , ISAVEY)  to  1001.  It  then  checks  the  target  type  from  the 
event  notice  (INVDT(29))  to  insure  it  is  a bridge,  road  or  x-y  point,  and 
gets  the  index  to  the  target  point  for  future  use.  If  the  designated  target 
is  a road,  it  loops  through  all  the  roads,  checking  each  road  segment  by 
calculating  the  center  ooint  of  each  segment  and  comparing  it  with  the 
target  coordinates.  The  last  center  point  whose  coordinates  are  both  less 
than  1001  meters  from  the  designated  target  is  then  used  as  the  target. 

If  the  target  is  a bridge  BRRDCHCK  loops  through  the  bridges  in 
the  model  and  calculates  each  bridge  center  point.  The  coordinates  of 
the  center  point  are  compared  with  the  target  coordinates.  If  both  are 
within  1001  meters  then  the  target  coordinates  are  changed  to  the  center 
of  the  bridge. 

As  long  as  some  bridge  or  road  segment  satisfies  the  test,  BRRDCHCK 
will  return  to  AIREVENT  and  the  mission  will  continue.  If  no  road  segment 
or  bridge  satisfies  the  test,  then  AIRERR0R  is  called  to  inform  the 
instructor  of  the  problem,  and  the  mission  continues. 

The  general  logic  flow  of  BRRDCHCK  is  illustrated  in  Figure  5-114. 

d.  ALERTGEN 

See  Section  5.7.2  for  a description  of  ALERTGEN. 

e.  ORDPRI 

0RDPRI  is  called  by  AIREVENT  when  the  mission  is  an  air  strike. 

The  purpose  of  ORDPRI  is  to  select  the  highest  priority  ordnance  on  board 
the  aircraft  for  the  target  designated  in  the  event  notice. 

ORDPRI  initializes  the  priority  (IFRSTPRI)  to  zero  and  gets  the 
target  type  (INVDT(29))  from  the  event  notice.  It  then  sets  up  an  index  (K) 
based  on  target  type  (unit,  bridge,  road,  x-y  point).  ORDPRI  then  loops 
through  the  equipment  types  (ITEQU)  carried  on  the  aircraft  for  the  strike 
missions.  When  it  finds  a weapon  that  has  a greater  than  zero  priority 
against  the  designated  target,  it  saves  the  priority  and  weapon  type  for 
subsequent  comparisons.  When  it  has  completed  the  loop  through  all  the 
equipments  carried  by  the  aircraft,  it  assigns  the  weapon  type  with  highest 
priority  to  the  variable  IBETA.  If  no  weapon  qualifies  to  be  used  against 


Page  5-780 


the  designated  target,  then  IBETA  is  set  to  zero.  ORDPRI  then  returns  to 
AIREVENT. 

The  general  logic  flow  of  ORDPRI  is  illustrated  in  Figure  5-115. 

f.  AIRABORT 

AIRABORT  is  called  by  AIREVENT  when  the  air  mission  is  cancelled. 
The  purpose  of  AIRABORT  is  to  set  the  air  abort  conditions  flag  to  TRUE, 
and  to  select  the  route  to  be  flown  back  to  base. 

AIRABORT  begins  by  calculating  the  unit  index  (IAU)  for  the  mission 
that  was  cancelled.  It  then  sets  the  condition  flag  (logical  variable 
AIRBORT)  to  TRUE.  AIRABORT  then  calculates  the  square  of  the  route  length, 
and  the  square  of  the  distance  remaining  on  the  route.  If  more  than  half 
of  the  route  remains  to  be  flown,  then  subroutine  SWITCH  is  called  to 
reverse  the  order  of  the  points  in  the  AIROUTES  common  block  ( IACPX , IACPY , 
IACPZ)  so  the  aircraft  actually  reverses  its  course  and  retraces  the  route 
of  flight.  If  less  than  half  the  route  remains  to  be  flown  the  aircraft 
continues  on  the  selected  route.  In  either  case,  the  airspeed  is  set  to 
cruise  airspeed  (R0ME( IAC,4) ) for  the  remainder  of  the  route.  AIRABORT 
then  returns  to  the  calling  routine,  AIREVENT. 

The  general  logic  flow  of  AIRABORT  is  illustrated  in  Figure  5-116. 

g.  SWITCH 

Subroutine  SWITCH  is  called  by  AIRABORT  to  reverse  the  entries 
in  an  array.  SWITCH  presumes  a maximum  of  nine  entries  to  be  reversed. 

SWITCH  utilizes  a one-word  temporary  storage  location  as  a 
holding  point  for  one  of  the  variables  being  reversed.  It  begins  by 
putting  word  #9  of  the  array  into  ITEMP,  then  moving  word  #1  to  the  #9 
location,  and  then  putting  the  contents  of  ITEMP  into  location  #1  of  the 
array.  The  switch  of  entries  #1  and  #9  of  the  array  is  now  complete. 

SWITCH  then  does  entries  #2  and  #8,  #3  and  #7,  and  #4  and  #6  to  complete 
the  reversal.  SWITCH  then  returns  to  the  calling  routine,  AIRABORT. 

The  logic  flow  of  SWITCH  is  illustrated  in  Figure  5-117. 

h.  CLEARDET 

CLEARDET  is  called  by  AIREVENT  once  for  every  new  air  mission. 


ENTER  J from  AIREVENT 


Figure  5-115.  General  Logic  Flow  of  ORDPRI 


Page  5-783 


Figure  5-117.  General  Logic  Flow  of  SWITCH 


The  purpose  of  CLEARDET  is  to  initialize  the  detection  and  previous 
engagement  arrays  for  this  air  mission. 

CLEARDET  sets  to  zero  the  ground-to-air  engagements  (IGADET)  and 
the  previous  engagements  (IPRVENG)  arrays.  It  then  sets  to  zero  the  air- 
to-ground  sensor  (IAGDET)  array  and  returns  to  the  calling  routine, 

A I REVENT. 

The  general  logic  flow  is  illustrated  in  Figure  5-118. 

5. 8. 1.2  AIRMOV  Chain 

AIRMOV  is  called  once  each  time-step  by  the  main  driver  program 
FORMAIN  to  compute  positions  for  each  air  unit  during  the  next  minute. 

If  the  mission  is  to  be  aborted  due  to  weather  or  command/control, 

AIRABORT  is  called  to  accomplish  a change  in  direction  if  the  air  unit 
has  completed  less  than  half  of  its  route.  (For  a description  of  AIRABORT, 
see  Section  5. 8. 1.1)  The  AIRMOV  chain  subroutine  linkage  is  shown  in 
Figure  5-110.  Table  5-57  presents  a brief  description  of  each  subroutine 
in  AIRMOV,  including  the  principal  inputs  and  outputs.  The  general  logic 
flow  of  AIRMOV  is  presented  in  Figure  5-119. 

Initially,  the  last  position  of  the  air  unit  in  the  previous  time-step 
( IXAIR, IYAIR, IZAIR)  is  transferred  to  the  first  position  this  time-step 
( IXOLD, IYOLD, IZOLD) . Next,  visibility  (VISM),  density  altitude  (DNSALT) , 
and  fuel  level  (CLAVGAS)  are  checked  to  determine  if  the  mission  is  to  be 
aborted  (visibility)  or  if  the  air  unit  will  crash  (density  altitude  and 
fuel).  An  appropriate  alert  is  generated  for  each  case.  Assuming  that  the 
air  unit  is  continuing,  the  differential  between  current  altitude  and 
velocity  and  that  specified  at  the  next  check  point  is  computed.  If  the 
next  check  point  is  a target  unit  which  could  be  moving,  the  next  check 
point  is  corrected.  The  distance  to  the  next  check  point  is  compared  with 
the  distance  to  be  covered  to  the  end  of  the  quarter  minute  at  present 
speed  to  determine  if  a change  in  direction  is  required.  If  a check  point 
is  reached  first,  time  of  arrival  at  the  check  point  is  computed.  The 
whole  process  of  computing  differentials  for  X,  Y,  Z to  the  next  check 
point  repeated  for  the  entire  one  minute  interval.  Fuel  used,  which  had 
be'*,  i rputed  for  each  subinterval  and  accumulated,  is  removed  from  the  air 
unit's  supply. 
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for  this  aircraft 
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Table  5-57.  AIRMOV  Chain  Subroutine  Descriptions  (Cont'd) 
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with  I EQCLS= 3 and 
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which  is  damaged  by 
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IU.  (1<IUS100) 

I YAIR< JAIRTE , JAU)  - Y-coordinate  of  air  unit 
JAU  at  JAIRTE-th  point  in  this 
minute.  There  are  4 quarter- 
minute  points  in  current  minute 
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Figure  5-118.  General  Logic  Flow  of  CLEARDET 
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Figure  5-119.  General  Logic  Flow  of  AIRMOV  Chain 
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Figure  5-119.  General  Logic  Flow  of  AIRMOV  Chain,  Cont'd. 
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Figure  5-119.  General  Logic  low  of  AIRMOV  Chain,  Cont'd. 
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Figure  5-119.  General  Logic  Flow  of  AIRMOV,  Cont'd. 
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Fuel  consumption  is  a particularly  complicated  and  non-linear  function 
of  a large  number  of  factors,  including  air  density,  airspeed,  aircraft  gross 
weight,  aircraft  drag  factor,  air  temperature  and  many  more.  In  order  to 
account  for  these  factors  and  still  provide  an  air  module  that  is  not  far 
too  complex  for  this  application,  a number  of  very  significant  simplifica- 
tions have  been  made.  The  factors  considered  in  the  fuel  consumption  model 
are  air  density,  aircraft  load,  climb/dive  rate  and  aircraft  speed.  Fuel 
consumption  has  been  assumed  to  be  a linear,  or  in  one  case,  a piece-wise 
linear,  function  of  these  four  factors.  The  factors  used  to  define  the 
curves  are  aircraft  type  dependent  and  are  input  as  a part  of  the  equipment 
input  deck.  The  definition  of  the  factors  and  the  corresponding  variable 
names  from  the  equipment  input  deck  are  shown  below: 

rdff 1 tap  71  Fuel  consumption  at  worst  air  density  , 

’ Fuel  consumption  at  best  air  density 


R0FE( IAC,6) 

ROFE(IAC.l) 
R0FE(IA C,2) 
ROFE ( IAC,3) 
R0FE( IAC,4) 
R0FE( IAC,5) 


Fuel  consumption  at  maximum  load  _ ^ 

Fuel  consumption  at  minimum  load 

Fuel  consumption  change  for  losing  altitude 

Fuel  consumption  change  for  gaining  altitude 

Fuel  consumption  rate  at  minimum  speed 

Fuel  consumption  rate  at  cruise  speed 

Fuel  consumption  rate  at  maximum  speed 


The  actual  consumption  curves  are  shown  in  Figures  5-120,  5-121,  5-122,  5-123, 
5-124  and  5-125.  In  the  model  the  curve  representing  Figure  5-125  is  calcu- 
lated from  the  airspeed  and  Figure  5-124. 


The  subroutine  descriptions  for  the  subroutines  called  by  AIRMOV  are 
as  follows:  for  AIRABORT  and  SW I TCH  see  Section  5.8.1;  and  for  ALERTGEN 

see  Section  5.7.2. 

5. 8. 1.3  AIRMQV2  Chain 

AIRM0V2  is  called  once  each  time-step.  It  loops  through  each  quarter 
minute  subinterval  to  examine  the  location  of  each  active  air  unit  at  the 
beginning  and  end  of  the  subinterval.  The  AIRM0V2  chain  subroutine  linkage 
is  shown  in  Figure  5-111.  Table  5-58  presents  a brief  description  of  each 
subroutine  in  AIRM0V2,  including  the  principal  inputs  and  outputs.  The 
general  logic  flow  of  AIRM0V2  is  presented  in  Figure  5-126. 
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Table  5-58.  AIRM0V2  Chain  Subroutine  Descriptions 
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Table  5-58.  AIRM0V2  Chain  Subroutine  Descriptions  (Cont'd) 
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Table  5-58.  AIRM0V2  Chain  Subroutine  Descriptions  (Cont'd) 
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Table  5-58.  AIRM0V2  Chain  Subroutine  Descriptions  (Cont'd) 
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Figure  5-121.  Aircraft  Fuel  Consumption  versus  Air  Density 
(Temperature  Dependent) 


Figure  5-122.  Aircraft  Fuel  Consumption  versus  Aircraft  Load 
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ALRCRAFT  RATE  OF  CLIMB  (METERS/ MI  MUTE) 


Figure  5-123.  Aircraft  Climb  Rate  versus  Fuel  Consumption 
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AIRCRAFT  DIVE  RATE  (METERS/MINUTE) 

Figure  5-124.  Aircraft  Dive  Rate  versus  Fuel  Consumption 
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Figure  5-125. 


AIRCRAFT  SPEED 


Calculations  of  Aircraft  Fuel  Consumption  as  a 
Function  of  Aircraft  Speed 
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Call  AIRCAS  for  determination 
of  amount  of  fire  and  resulting 
casual  ties 


Reduce  air  unit  (aircraft,  per- 
sonnel, equipment)  by  tne  com- 
puted casualty  fraction 


Call  AIRGRND  to  generate  an 
alert  If  ground  unit  IGU  was 
detected  by  air  unit  IAU 
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Does  IGU  = 
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^ air  unit  have 
a ground  target  to 
fire  at  this  quarter, 
minute?  / 


Call  ADW  to  accomplish  ordnance 
delivery  and  the  resulting 
casualty  assessment 


Figure  5-126.  General  Logic  Flow  of  AIRM0V2  Chain,  Cont'd. 


Issue  alerts  for  all  air  units 
Incurring  damage 


Call  AIRCAS1  to  place  personnel 
manning  air  defense  weapons  in 

their  correct  vulnerability 
classes 


Figure  5*126*  General  Logic  Flow  of  mIRFiOV2  Chain,  Cont  d. 
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AIRM0V2  checks  all  ground  units  of  the  opposite  color  to  determine  if 
detection  by  the  ground  unit  has  taken  place  (via  a call  to  GRNDAIR).  (For 
a description  of  GRNDAIR,  see  Section  5.3.2.)  If  so,  the  ground  unit  will 
consider  firing  at  the  air  unit  (via  a call  to  AIRCAS)  if  the  ground  unit 
has  not  already  fired  at  another  air  unit  and  it  is  in  an  air  defense  state 
which  allows  it  to  fire  at  the  opposing  air  unit.  If  any  aircraft  are  lost 
from  the  air  defense  fire,  the  number  of  aircraft  lost  and  a proportionate 
number  of  personnel  and  equipment  are  removed  from  the  air  unit.  Detection 
by  the  air  unit  of  the  ground  unit  is  next  checked  (via  a call  to  A1RGRND). 
(For  a description  of  AIRGRND,  also  see  Section  5.3.2.)  If  the  air  unit  is 
on  an  air  strike  mission  scheduled  to  occur  this  subinterval,  the  ordnance 
deliver  is  accomplished  (via  a call  to  ADW),  along  with  the  computation  of 
ground  casualties.  The  entire  process  is  repeated  for  all  air  units  for 
one  subinterval,  then  the  next  of  the  four  subintervals  is  processed. 

Each  air  unit  is  checked,  via  a call  to  CK4XING,  to  see  if  its  flight 
during  this  minute  violated  any  control  measures.  If  so,  CK4XING  issues 
an  alert  for  each  violated  control  measure.  Each  air  unit  is  also  checked 
to  see  if  it  has  incurred  losses  resulting  from  ground-air  fire.  If  so, 
an  alert  is  issued  indicating  the  losses.  Personnel  manning  the  ground-air 
defense  fire  weapon  are  distributed  over  their  personnel  vulnerability 
classes  as  a function  of  whether  or  not  the  weapon  has  been  fired  any  time 
this  minute  (via  a call  to  AIRCAS1). 

Brief  descriptions  of  the  subroutines  called  by  AIRM0V2  follow: 

a . AIRCAS 

AIRCAS  is  called  by  AIRM0V2  wherever  a grcund  unit  has  detected 
an  enemy  air  unit  during  a particular  quarter-minute  subinterval,  is  in 
an  air  defense  state  allowing  him  to  fire  at  the  air  unit,  and  has  not  yet 
fired  his  air  defense  weapons  this  quarter-minute.  AIRCAS  computes  the 
number  of  rounds  fired  by  each  air  defense  weapon  in  the  ground  unit  and 
their  effect.  The  general  logic  flow  of  AIRCAS  is  illustrated  in  Figure 
5-127. 

For  each  air  defense  weapon  in  the  ground  unit,  each  point  of 
the  air  unit's  movement  during  that  quarter-minute  (two  endpoints  plus 
any  check  points  between  them)  is  examined  pairwise.  If  it  passes  three 


Page  5-830 


From  AIRM0V2 


Compute  altitude  ana  slant  range  be- 
twwn  ground  unit  and  air  unit  for 
each  point  in  the  quarter  minute 


INDX  = 1st  equipment  in 
ground  unit 


Equipment 
an  air  defense 
weapon?  ^ 


Calculate  exposure  time  of  aircraft  to  ground 

unit  based  on  satisfaction  of  three  criteria  at 
e*CTi  position  point: 

!1)  Within  range  of  weapon 
21  Within  altitude  of  weapon 
3)  Detected  by  ground  uni t 


Exposure  time  = 0? 


Figure  5-127.  General  Logic  Flow  of  Subroutine  AIRCAS 


Page  5-831 


Figure  5-127.  General  Logic  Flow  of  Subroutine  AIRCAS  (Continued) 
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checks;  namely,  1)  within  altitude  range  of  weapon,  2)  within  slant 
range  of  weapon,  3)  detection  occurred  at  the  point,  then  the  point  is 
counted.  If  the  other  point  of  the  pair  is  also  counted,  firing  occurs 
for  the  whole  interval  of  time.  If  just  one  point  of  a pair  passes,  the 
duration  of  firing  over  that  pair  of  points  is  generated  stochastically 
from  a uniform  distribution.  All  pairs  of  points  in  the  quarter-minute 
are  examined  this  way,  and  the  total  duration  of  fire  is  computed.  This 
duration  is  multiplied  by  the  firing  rate  per  gun,  the  number  of  such  guns 
in  the  unit,  and  the  suppression  factor  of  the  unit  to  yield  the  total 
number  of  rounds  fired.  Ammunition  levels  are  reduced  for  the  weapon  fired. 
PRNTFIR  is  called  to  save  appropriate  data  for  the  air  defense  fire  report, 
FINFUN  is  called  to  find  the  weapons  effects  function  used  to  compute  possi- 
ble air  losses,  and  EFFNS  performs  the  actual  casualty  computation.  ADFALERT 
is  called  to  generate  appropriate  air  defense  alerts. 

b.  ADFALERT 

This  subroutine  is  called  either  by  AIRM0V2  or  A1RCAS  fcr  each 
ground  unit/opposite  colored  air  unit  pairing.  If  the  ground  unit  has 
changed  either  from  a firing  to  non-firing  or  non-firing  to  firing  state, 
an  alert  is  issued.  Otherwise,  it  simply  returns.  The  general  logic  flow 
of  ADFALERT  is  presented  as  Figure  5-128. 

c.  ADW 

The  philosophy  governing  air  ordnance  delivery  has  been  modified 
since  the  CATTS  system  was  originally  delivered  to  the  Army  in  May,  1975, 
per  Army  request.  Originally  air  units  delivered  ordnance  against  a 
specified  unit  and  all  equipment  in  the  unit,  as  well  as  personnel,  was 
examined  to  assess  the  effect  of  the  ordnance.  No  specific  equipment  type 
in  the  target  unit  was  attacked  directly.  After  using  the  system  for 
approximately  four  months,  the  Army  came  to  the  conclusion  that  the  delivery 
of  air  ordnance  could  only  be  modeled  realistically  if  specific  equipment 
types  were  attacked.  This  was  especially  true  for  guided  weapons,  which 
are  by  far  the  most  effective.  This  change  affected  the  logic  of  subroutine 
ADW.  Therefore,  the  description  that  follows,  and  the  reference  figure 
containing  the  logic  flow  of  the  subroutine,  differ  considerably  from  the 
documentation  in  the  CATTS  Programming  Report. 
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ADW  is  called  by  AIRM0V2  when  the  calling  routine  is  processing  an 
air  unit  having  a designated  ordnance  deliver  point  in  the  quarter-minute 
subinterval  currently  being  processed.  The  general  logic  flow  of  ADW  is 
presented  as  Figure  5-129. 

ADW  uses  ordnance  attributes  to  compute  the  number  of  separate 
drops  required  to  deliver  the  ordnance,  the  distance  between  drops  if  more 
than  one  is  required,  and  the  total  amount  of  ordnance  delivered  per  drop 
considering  the  number  of  aircraft  in  the  air  unit.  The  probability  of  a 
dud  is  accounted  for  by  removing  duds  from  the  load  based  on  a random 
number  draw.  Average  ballistic  errors  are  calculated  (via  a call  to 
ADWDATA)  in  range  and  deflection  relative  to  the  air  unit’s  direction  of 
movement,  and  subjected  to  a normally  distributed  random  number  generator 
with  zero  mean.  The  range  and  deflection  errors  are  transformed  to  the 
X,  Y plane  in  order  to  compute  the  impact  point,  as  depicted  in  Figure  5-130. 
An  alert  is  issued  indicating  the  impact  point  and  type  of  ordnance.  The 
impact  point  is  stored  for  impacting  fires  display  the  next  minute.  A 
lethal  area  around  the  impact  point  is  computed,  as  shown  in  Figure  5-131, 
for  the  ordnance  from  parameters  computed  by  ADWDATA  from  mean  area  of  effec- 
tiveness against  personnel  standing  in  the  open.  For  air  units  having  a 
non-unit  target  (bridge,  road,  or  area  target),  each  ground  unit,  both 
friendly  and  enemy,  is  checked  for  overlap  with  the  lethal  area  (via  a 
call  to  FRFD).  Any  unit  having  a non-zero  overlap  is  flagged.  Personnel 
casualties  are  computed  by  means  of  an  ordnance-defined  fraction  of 
casualties  in  the  overlap  area  for  each  vulnerability  class.  Casualties 
are  integerized  via  a random  number  call,  and  appropriate  casualty  tables 
are  updated.  Equipment  losses  for  equipments  in  class  1 ( I EQCLS  = 1),  soft 
targets,  are  computed  similarly.  Each  equipment  type  has  an  attribute 
(IEQCLS)  describing  its  vulnerability  to  an  air  strike.  Only  target 
equipments  with  this  attribute  set  for  soft  target  (=1)  are  processed. 

Soft  targets  have  a fraction  defined  that  is  used  to  determine  the  lethal 
overlap  area.  Equipment  losses  are  integerized  and  appropriate  tables 
updated.  If  an  equipment  loss  carries  with  it  related  personnel  casualties, 
personnel  are  removed  from  the  vulnerability  class  having  the  largest 
number  of  personnel.  An  alert  is  generated  at  the  completion  of  the  strike 
for  each  unit  incurring  casualties.  After  all  units  have  been  completed, 
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Figure  5-129.  General  Logic  Flow  of  Subroutine  ADW 
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Figure  5-129.  General  Logic  Flow  of  Subroutine  ADW  (Cont'd.) 
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Figure  5-129.  General  Logic  Flow  of  Subroutine  ADW  (Cont'd.) 
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Figure  5-129.  General  Logic  Flow  of  Subroutine  ADW  (Cont'd.) 
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Notes  to  Figure  5-129: 

(1)  The  number  of  total  projectiles  of  the  type  to  be  fired  from  the 
air  unit  ( USEEQU ( I ,JJ) ) is  compared  with  the  quantity  resulting 
from  the  number  of  projectiles  usually  dropped  in  a standard 
delivery  per  aircraft  ( I AMTE ( IBETA.2) ) times  the  number  of  air- 
craft (USEEQU(I.l)).  If  the  first  quantity  (USEEQU ( I , JJ ) ) is 
smaller,  only  one  drop  is  required.  Otherwise,  the  number  of 
drops  is  taken  from  variable  IAMTE( IBETA.4) , the  distance  between 
drops  from  I AMTE ( IBETA,5) , the  total  number  of  projectiles  over 
all  drops  ( AMTF I RED ) is  computed  as  the  number  usually  dropped 

in  a standard  delivery  per  aircraft  times  the  number  of  aircraft, 
and  tne  number  delivered  per  drop  (IEND)  as  the  number  of  projec- 
tiles per  drop  per  aircraft  times  the  number  of  aircraft. 

(2)  The  target  equipment  with  the  highest  classification  as  an  air 
target  (IEQCLS)  for  which  the  projectile  has  a non-zero  kill 
probability  is  used  as  the  selected  target  element.  If  more 
than  one  type  of  target  element  has  the  highest  classification, 
the  one  with  the  largest  weighting  factor  (UBE)  is  chosen. 

(3)  If  the  random  number  draw,  RANDU( IRAND) , is  less  than  the  frac- 
tional part  of  the  casualty  accumulations,  increment  the 
integer  part  by  1;  otherwise,  truncate  the  fractional  part. 

(4)  See  Section  4 for  a description  of  the  STATS  array. 

(5)  Personnel  are  removed  from  the  vulnerability  class  having  the 
largest  number  first,  then  the  next  largest  number,  and  so  on 
until  all  casualties  are  accounted  for. 

(6)  If  no  bonafide  equipment  targets  remain  in  a target  unit  and 
some  guided  projectiles  remain  unused,  the  remaining  ones  are 
used  against  "hard  bunkers".  Hard  bunkers  as  such  are  not 
modeled  as  entities  in  CATTS.  However,  to  satisfy  a model 
enhancement  requested  by  U.  S.  Army  and  U.  S.  Air  Force  personnel 
in  Fort  Benning,  Georgia,  this  feature  was  added.  The  variable 
R0FE( I BETA , 1 ) was  defined  to  represent  the  number  of  personnel 
casualties  resulting  from  a guided  projectile  destroying  a hard 
bunker  or  personnel  fortification.  To  each  unused  guided  pro- 
jectile is  attributed  the  number  of  casualties  specified  by 
R0FE( IBETA , 1 ) up  to  a maximum  equal  to  the  sum  of  the  number  of 
personnel  in  vulnerability  classes  1 and  2 (see  equation  56  in 
Section  5. 8. 3. 3). 


Figure  5-129.  General  Logi  flow  of  Subroutine  ADW  (Cont'd.) 
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— = aircraft  flight  path 
A = aim  point 
I = impact  point 
R = range  error 
D = deflection  error 

(R,  0)  = n(f1(v,z,t),f2(v,z,t)) 

F-j , F^  = table  look  up  functions 

N = stochastic  normal  distribution  function 
V = aircraft  speed 
Z = aircraft  al titude 
T = ordnance  type 


Figure  5-130.  Calculation  of  Impact  Point  of 
Air  Delivered  Ordnance 
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1 = calculated  impact  point 
PTLimi  = yJK/J 
PTWDTH  = 3 * PTLNTH 

A = calculated  "Lethal  area"  of  ordnance 
= F(V,Z,T) 

V = aircraft  speed 
Z = ai rcraft  al ti tude 


T = ordnance  type 


Figure  5-131.  Calculation  of  Impact  Area  of  Air 
Delivered  Weapons 
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bridges  and  roads  are  checked  to  determine  if  the  impact  point  of  each  drop 
affects  any  bridge  or  road  defined  in  the  data  base  (via  a call  to  OTHRDMG). 
If  any  bridge  or  road  segment  is  affected,  damage  is  computed  (via  a call 
to  DIDITHIT).  If  the  strike  is  not  yet  completed,  a separation  distance 
"delta"  is  added  to  the  last  impact  point,  the  next  point  of  impact  is 
calculated,  and  the  casualty  assessment  process  is  repeated. 

For  air  units  having  a unit,  or  hard,  target  designated,  the 
equipment  type  in  the  target  unit  with  the  highest  equipment  class  (repre- 
senting its  value  as  an  air  target)  is  selected  for  direct  attack.  If 
more  than  one  equipment  type  has  the  highest  classification,  the  equipment 
weighting  factor  (UBE)  is  used  to  determine  the  equipment  type.  The  kill 
probability  is  compared  against  a random  number  to  determine  whether  or  not 
that  particular  projectile  was  effective.  All  projectiles  of  a given  drop 
are  evaluated  similarly  until  exhausted.  If  the  equipment  type  is  completely 
destroyed  before  all  projectiles  are  used,  the  next  qualifying  target  equip- 
ment is  selected.  In  the  special  case  where  not  all  guided  projectiles 
(ORDTYP  = 10)  have  been  used,  but  no  equipment  types  oualifv  as  hard  targets, 
highly  invulnerable  personnel  in  vul nerabi 1 i ty  classes  1 and  2 (assumed  to 
be  in  hard  fortifications,  such  as  bunkers)  are  used  as  direct  targets. 

Note  (6)  to  the  subroutine  ADW  flow  chart  discusses  this  case  in  more 
detail.  All  casualties,  both  equipment  and  personnel,  are  accumulated 
in  the  casualty  reporting  array  (STATS).  For  equipment  casualties,  related 
personnel  casualties  are  also  computed,  representing  the  number  of  personnel 
killed  when  an  equipment  type  is  destroyed  (for  example,  when  a tank  is 
destroyed,  the  crew  operating  the  tank  also  incurs  casualties). 

When  all  direct  target  casualties  have  been  completed,  the  loop 
described  above  for  bridge,  road,  or  area  targets  is  entered  to  evaluate 
secondary  (proximity)  casualties  resulting  from  the  direct  strike.  All 
units  are  processed  for  possible  secondary  casualties.  When  this  loop  is 
completed,  the  casualty  assessment  due  to  an  air  unit  delivering  its 
ordnance  is  completed.  The  amount  of  ordnance  delivered  is  removed  from 
the  air  unit's  ordnance  load. 

Figure  5-132  illustrates  the  strike  pattern.  Table  5-53  summarizes 
the  lethality  calculations  made  for  air-delivered  weapons. 
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a.  Single  Drop 
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b.  Even  Number  of  Drops 


c.  Odd  Number  of  Drops 
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Figure  5-132.  Actual  Impact  Points  for  Three  Air  Strike  Situations 
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d.  ADWDATA 

ADWDATA  is  called  by  ADW  each  time  an  air  strike  occurs.  ADWDATA 
uses  the  air  unit  location  at  the  time  of  ordnance  delivery  (including 
altitude  and  velocity)  and  the  ordnance  type  being  delivered  to  compute 
range  and  deflection  probable  errors  and  pattern  length  and  width  of 
lethal  area.  The  general  logic  flow  of  ADWDATA  is  presented  as  Figure  5-133. 

Air  ordnance  for  the  purposes  of  ballistic  error  lethal  area  calcu- 
lations can  be  grouped  in  the  following  categories: 

(1)  low-drag  bombs  and  napalm 

(2)  hi -drag  bombs 

(3)  guided  mi ssi les 

(4)  CBU-2 

(5)  Rockeye  and  CBU-24 

(6)  Rockets  and  Cannons 

For  low-drag  bombs  and  napalm,  the  time  of  fall  and  impact  angle 
are  computed  from  the  aircraft  altitude  and  velocity.  The  impact  angle 
is  used  along  with  the  bomb  coefficients  to  compute  lethal  area.  Ballistic 
errors  are  a function  of  aircraft  altitude  and  time  of  fall,  along  with  the 
bomb  coefficients.  Hi-drag  bombs  are  done  similarly  except  that  the  time  of 
fall,  ground  range  between  target  and  aircraft  at  weapon  release,  and  impact 
angle  are  selected  by  table  look-up  for  the  appropriate  velocity  and  altitude. 

Guided  missiles  have  zero  ballistic  errors.  Their  lethal  area  is 
constant  such  that  the  width  = 3 x length. 

For  the  CBU-2  cluster  bomb,  time  of  fall  and  slant  range  are  com- 
puted as  a function  of  altitude,  which  in  turn  are  used  along  ,:;*h  the 
ordnance  coefficients  to  determine  ballistic  errors.  Letha1  area  of  a 
CBU-2  is  computed  from  a pre-determined  constant,  but  modi' ied  ac.  a function 
of  the  aircraft  altitude  at  delivery.  Lethal  area  width  ; 3 x length. 

For  the  CBU-24  and  Rockeye,  the  ballistic  errors  are  identical  and 
constant,  whereas  the  CBU-24  has  constant  lethal  area  and  a Rockeye's  lethal 
area  depends  on  the  impact  angle,  which  is  determined  by  aircraft  altitude 
and  velocity  at  release.  The  lethal  area  width  3 x length. 


Convert  aircraft  velocity  from  meters /minute 
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Figure  5-133.  General  Logic  Flow  of  Subroutine  ADWDATA 
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For  the  rockets  and  cannon,  the  lethal  areas  are  constant  but  not 
identical.  Ballistic  errors  are  calculated  as  a function  of  altitude. 

The  equations  for  calculating  lethal  area  for  the  different  air- 
delivered  ordnance  types  are  presented  in  Table  5-59.  A brief  description 
of  the  data  tables  used  in  ADWDATA  are  presented  in  Table  5-60. 

At  the  conclusion  of  processing,  all  units  are  converted  back  to 
meters  for  use  by  ADW. 

e.  NORMA L 

This  subroutine  is  given  a mean  and  standard  deviation  as  arguments, 
and  produces  a normally  distributed  random  sample  as  a result.  It  accom- 
plishes this  by  sampling  12  times  from  a uniform  (0,1)  random  number  gene- 
rator, then  performing  the  following  computation: 

RVNORM  = (A  - 6.0)  * XSTDEV  + XMEAN 

where 

RVNORM  is  the  desired  result 

A is  the  cumulative  sum  of  the  12  uniform 
(0,1)  samples 

XSTDEV  is  the  standard  deviation 
XMEAN  is  the  mean 

The  general  logic  flow  of  NORMAL  is  presented  as  Figure  5-134. 

f.  FRED 

Two  parallel  rectangles  transformed  to  the  X,  Y coordinate  system, 
one  representing  the  unit,  the  other  the  lethal  area,  are  checked  to  deter- 
mine the  area  of  overlap.  This  area  is  then  divided  by  the  unit  area  to 
yield  the  fraction  of  the  unit  in  the  lethal  area.  The  calculation  is 
quite  simple.  The  maximum  of  the  smaller  X values  of  the  two  rectangle1 
is  subtracted  from  the  minimum  of  the  larger  X values;  similarly  for  Y. 

If  either  of  these  subtractions  produces  a non-positive  result,  there  is 
zero  overlap.  Otherwise,  the  X and  Y differences  represent  the  sides  of 
the  overlap  area,  which  is  divided  by  the  unit  area  to  yield  the  desired 
result. 

The  general  logic  flow  of  FRFD  is  presented  in  Figure  5-135. 
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Table  5-60.  ADWDATA  Data  Tables 


Data  Variable 

Dimension 

Description 

IV 

6 

Table  of  "break"  velocities  (in  knots). 

IA 

7 

Table  of  "break"  altitudes  (in  feet). 

GR 

(7,  6,  3) 

Table  of  ground  ranges  (in  feet)  as  a 
function  of  altitude,  velocity  and  ord- 
nance type. 

TF 

(7,  6,  3) 

Table  of  time  of  fall  as  a function  of 
altitude,  velocity  and  ordnance  type. 

XMAEGP 

(5,  2) 

Table  containing  a maximum  and  minimum 
mean  area  of  effectiveness  as  a functioi 
of  impact  angle  for  the  five  types  of 
general  purpose  low-drag  bombs. 

LARKI 

(2,  7) 

Table  of  impact  angles  (1,  IA)  and 
lethal  areas  (2,  LA)  for  seven  break 
values  of  impact  angle  for  the  Rockeye. 

IMA 

(7,  6,  4) 

Table  of  impact  angles  expressed  as  a 
function  of  altitude,  velocity,  and 
ordnance  type  (the  three  high-drag 
general  purpose  bombs  and  Rockeye). 

CBU24RSD 

(7,  6) 

Table  of  standard  deviations  of  impact 
error  distances  in  range  for  the  CBU24, 
given  as  a function  of  altitude  and 
veloci ty . 

CBU24DSD 

(7,  6) 

Table  of  standard  deviations  of  impact 
error  distance  in  deflection  for  the 
CBU24,  given  as  a function  of  altitude 
and  velocity. 
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Figure 


-134.  General  Logic  Flow  of  Subroutine  I.ORfiAL 
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Figure  5-135.  General  Logic  Flow  of  Subroutine  FRi  D 
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g.  OTHRDMG 

This  subroutine  is  called  for  each  drop  of  an  air  strike  to  asspss 
possible  damage  to  bridges  and  road  segments.  It  sets  up  a call  to  sub- 
routine DIDITHIT  for  each  bridge  not  yet  destroyed,  and  for  any  bridge 
affected  by  the  drop  (in  DIDITHIT),  accumulates  damage  and  generates  an 
alert.  It  then  checks  each  road  segment  not  yet  destroyed.  Any  road 
within  1000  meters  in  both  X and  Y is  sent  to  DIDITHIT  for  damage  evalua- 
tion. The  results  are  accumulated  for  the  road  segment  and  an  alert  is 
generated. 

The  general  logic  flow  of  OTHRDMG  is  presented  as  Figure  5-136. 

h.  DIDITHIT 

This  subroutine  is  called  by  OTHRDMG  each  time  a bridge  or  road 
segment  is  to  be  evaluated  for  damage  resulting  from  a drop  of  an  air 
stri ke. 

For  evaluation  against  either  a bridge  or  road  segment,  individual 
impact  points  for  each  piece  of  ordnance  in  the  drop  are  computed.  The 
impact  locations  are  separated  by  10  meters  in  both  X and  Y and,  for 
bridges,  each  impact  location  is  checked  to  see  if  it  falls  within  the 
bridge  area.  For  road  segments,  a crater  is  built  around  each  impact 
point,  the  crater  size  being  determined  by  the  road  type.  The  largest 
width  of  the  road  segment  destroyed  is  accumulated  for  the  road  segment  to 
a maximum  of  1 . In  computing  the  fraction  of  road  segment  destroyed,  it  is 
necessary  to  first  determine  if  the  impact  location  fell  inside  the  road 
segment.  If  so,  half  the  crater  radius  is  added  to  the  difference  between 
half  the  road  width  and  the  distance  between  the  road  center  and  impact 
point.  If  impact  was  off  the  road  segment,  it  suffices  to  compute  the 
difference  between  the  crater  radius  and  the  distance  between  the  impact 
point  and  the  closest  edge  of  the  road.  For  bridges  only,  a flag  is  set 
indicating  damage;  whereas  for  roads,  the  fraction  damaged  is  calculated 
as  wel 1 . 


The  general  logic  flow  of  DIDITHIT  is  presented  as  Figure  5-137. 
5.8.2  Assumptions  and  Data  Sources 


The  assumptions  used  in  constructing  the  CATTS  Air  Module  are: 


L 
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Figure  5-137.  General  Logic  Flow  of  Subroutine  DIDITHIT 
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Figure  5-137.  General  Logic  Flow  of  Subroutine  UIDITHIT  (Continued) 
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1)  A maximum  of  ten  air  missions  may  be  conducted  concurrently. 
Each  air  mission  becomes  a unit  while  in  progress,  there- 
fore, using  up  the  space  allotted  for  one  of  the  99  total 
units  allowed  in  the  simulation.  The  number  of  concurrent 
air  missions  allowed  in  any  scenario  is  user  input  to  any 
number  less  than  or  equal  to  the  maximum  of  ten.  Whatever 
this  number  may  be,  that  number  of  units  must  be  unused  and 
reserved  for  use  by  air  units  as  they  are  created. 

d)  Air  units,  and  air  missions,  are  created  dynamically  in 

response  to  command  and  control  inputs  from  the  controllers. 
Each  air  unit/mission  exists  only  until  it  is  completed. 

When  the  mission  is  completed,  the  air  unit  becomes  defunct, 
and  the  space  in  the  data  tables  used  by  the  now-defunct  air 
unit  becomes  available  for  use  by  the  next  air  unit  to  be 
created. 

3)  Air  missions  can  be  "canned"  in  either  of  two  ways. 

a)  CATTS  allows  the  input  of  pre-determined  command  and 
control  events  scheduled  to  occur  at  a specific  time. 

In  this  way,  a series  of  air  strikes  can  be  preplanned 
to  happen  at  exactly  the  same  time  each  time  CATTS  is 
exercised.  This  feature  is  extremely  useful  for  taking 
the  load  off  the  controllers  early  in  the  exercise.  It 
is  also  valuable  for  the  aggressor  forces,  whose  tactics 
and  actions  are  more  predictable  than  those  of  the  offi- 
cers being  trained. 

b)  CATTS  allows  the  input  of  up  to  ten  "Preplanned  Missions", 
each  comprised  of  a variable  number  of  command  and  con- 
trol events.  The  only  restriction  is  that  a total  of 
one-hundred  or  fewer  events  for  all  ten  missions  is 
allowed.  These  preplanned  missions  have  the  advantage 
that  the  time  at  which  they  are  to  occur  is  under  the 
dynamic  control  of  the  controllers,  which  provides  con- 
siderably more  flexibility.  It  is  also  feasible  to  have 

a generic  preplanned  air  strike  and  modify  only  the  tar- 
get point  each  time  it  is  used  (using  the  Change  Air 
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Mission  feature  of  the  Command  and  Control  System),  since 
this  allows  the  controller  control  over  both  time  and 
target,  yet  requires  less  interaction  than  planning  the 
air  mission  from  scratch  each  time. 

4)  The  controllers  are  given  three  capabilities  with  regard  to 
command  and  control  of  air  units. 

a)  A new  mission/unit  may  be  created  from  scratch. 

b)  An  existing  mission  may  be  cancelled. 

c)  An  existing  mission  may  be  changed. 

5)  An  "air  mission"  consists  of  a unit  and  up  to  nine  associated 
air  route  points.  Each  route  point  consists  of  an  x coordinate, 
a y coordinate,  an  altitude,  and  a speed.  One  of  the  route 
points  may  also  be  designated  as  a target,  which  may  be  a ground 
unit,  an  x,y  coordinate,  a road,  or  a bridge.  The  ground  trace 
of  the  flight  between  the  route  points  follows  the  straight  line 
segmerts  connecting  those  points  on  the  map.  The  altitude 

and  speed  are  adjusted  dynamically  each  15  seconds  until 
they  reach  the  altitude  and  speed  for  the  next  route  point. 

The  adjustments  made  are  within  input  aircraft  performance 
limits  for  each  aircraft  type. 

6)  The  air  movement  model  is  a time  step  model,  because  of  the 
high  speeds  of  aircraft,  the  time  step  used  by  air  movement 
is  nominally  15  seconds  instead  of  60  seconds  and  can  be 
changed  by  input  to  be  even  less  than  15  seconds. 

7)  Because  of  the  shorter  time  step  for  air  units,  each  air 
unit  actually  has  at  least  four  locations  per  math  model 
time  step.  The  location  at  the  beginning  of  the  time  step 
is  also  required,  making  at  least  five  locations.  In  addi- 
tion, any  air  route  points  reached  during  the  math  model 
time  step  are  saved,  since  they  normally  represent  a change 
of  direction.  Thus,  a total  of  up  to  eight  locations  for 
each  air  unit  is  calculated  and  stored  every  math  model 
time  step.  It  is  necessary  to  store  them  all  in  order  to 
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coirpute  air  to  ground  interactions  and  also  for  purposes 
of  display. 

d)  No  interactions  between  air  units  are  modeled. 

y)  Air  units  always  locate  and  identify  their  assigned  targets 
successfully.  The  assumption  is  that  there  is  a FAC  and  he 
is  able  to  perform  successfully. 

iO)  Air  units  are  unable  to  attack  any  target  unless  specifi- 
cally designated  by  the  controller  through  the  command  and 
control  menu.  The  exceptions  to  this  are  canned  and  pre- 
planned air  missions,  which  may  have  designated  targets  built 
iii. 

1’)  An  air  unit  is  an  entity  composed  of  one  or  more  aircraft 
of  the  same  type,  flying  in  a single  formation. 

12)  All  computations  use  flat  earth  geometry. 

3)  No  air-to-air  detections  or  engagements  are  modeled. 

14)  A tactical  fighter,  flying  at  top  speed  of  1250  knots, 
travels  38.5  km/min.  Even  at  cruise  speed  of  520  knots, 
it  travels  16  km/min.  This  means  that  in  a typical  15- 
second  move  it  may  advance  4 km  across  the  gaming  area. 

Since  the  range  of  many  air  defense  weapons  is  on  the 
order  of  7 50  meters  to  1200  meters,  the  air  unit  may  be 
out  of  range  at  either  end  of  its  move,  yet  directly 
overfly  the  weapons.  Further,  it  may  be  undetectable 
during  overflight.  The  converse  is  also  true,  which 
affects  aerial  detection  models,  particularly  during 
surveillance  and  reconnaissance  missions.  The  result 
is  that  air-to-ground  and  ground-to-air  firing  and  tar- 
get acquisition  models  have  to  be  differentiated  from 
the  ground-to-ground  models,  in  that  they  require 
greater  continuity  of  action.  Ground  units  look  for 
and  shoot  at  targets  only  at  the  end  of  each  move,  and 
the  fire  continues  for  an  entire  minute.  If  air  units 
behaved  similarly,  even  at  15-second  intervals,  the 
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results  would  be  unacceptable.  The  computational  require- 
ments of  realistic  1 i ne-of-sight  calculations  between  air 
and  ground  units  quickly  become  unacceptable,  since  what 
is  needed  is  a verdict  as  to  whether  any  point  on  a 16  km 
path  is  intervisible  with  the  ground  unit.  Therefore, 

1 i ne-of-sight  between  air  and  ground  units  is  assumed  to 
exist. 


15)  Air  movement  assumes  no  terrain  interaction  for  air  units. 
Specifically,  relief  and  vegetation  do  not  affect  LOS 
between  air  units  and  ground  units.  Also,  it  is  assumed 
that  the  flight  plan  altitudes  as  input  by  the  controller 
are  sufficient  to  clear  terrain  and  vegetation.  Thus, 
the  air  movement  model  will  fly  an  air  unit  at  the  input 
altitudes  regardless  of  whether  this  is  in  fact  possible. 

16)  An  aircraft  is  an  entity  described  by  the  following  charac- 
teristics for  each  aircraft  type.  The  characteri Stic  i s 
input  as'  a part  of  the  aircraft  equipment  for  each  ^fecific 
aircraft  type. 


Variable  Name 


Aircraft  Characteristic 


ILLMAN 
R0ME( IAC, 1 ) 
R0ME( IAC,6) 


R0ME( IAC,2) 
R0ME( IAC,3) 
R0ME( IAC,4) 
ROME (I AC, 5) 
R0FE( IAC ,3) 
R0FE(IAC,4) 
ROFE ( IAC, 5) 
ROFE(IAC.l) 


Crew  size 

Maximum  load  at  best  modeled  air  density 
Maximum  load  at  worst  modeled  air  density 
(correct  value  chosen  here  defines  worst 
density  at  which  aircraft  can  become 
airborne) 

Maximum  altitude  capability 
Minimum  flight  speed  capability 
Cruise  speed 
Maximum  speed 

Fuel  consumption  rate  at  minimum  speed 
Fuel  consumption  rate  at  cruise  speed 
Fuel  consumption  rate  at  maximum  speed 
Fuel  consumption  change  for  losing  alti- 
tude 


4s  m*-  m mmm  **  mm 
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Variable  Name 


Aircraft  Characteristic 


ROFE( 1AC,2) 

ROFE(IAC,b) 

ROFE( I AC , 7 ) 
R0ME(IAC,8) 

ROFE( IAC ,8) 
ROME( IAC,7) 

IAMTE(IACJ) 
I AMT  E ( I AC, 2) 
EQCAFAC 


Fuel  consumption  change  for  gaining  alti 
tude 

Fuel  consumption  at  maximum  load  _ ^ 

Fuel  consumption  at  mimrnun  load 

Fuel  consumption  at  worst  ai r density 
Fuel  consumption  at  best  air  density 

Maximum  acceleration/deceleration  capa- 

b i 1 i ty 

Maximum  climb/dive  capability 

Poorest  meteorological  visibility  in 

which  aircraft  may  conduct  a mission 

Takeoff  delay  time 

Landing  delay  time 

Fuel  capacity  of  aircraft 


An  air  equipment  type  other  than  an  aircraft  is  defined  by  the 
following  attributes: 


Variable  Name 
I PVCE( I EQ, 1 -8) 

IMINRE(IEQ) 
IMAXRE(IEQ.l) 
R0ME( I EQ , 4 ) 
ROME ( I EQ , 5 ) 
R0ME( IEQ,2) 
R0ME( I EQ , 3 ) 
ROME ( I EQ , 1 ) 


Equipment  Characteristi c 

List  of  up  to  eight  allowable  aircraft 
types  on  which  this  equipment  may  be 
used 

Minimum  range  at  which  equipment  may  be 
used  (to  prevent  aircraft  damage) 
Maximum  range  at  which  equipment  may  be 
used 

Minimum  altitude  at  which  equipment  may 
be  used 

Maximum  altitude  at  which  equipment  may 
be  used 

Minimum  speed  at  which  equipment  may  be 
used 

Maximum  speed  at  which  equipment  may  be 
used 

Weight  of  equipment  including  standard 
ammun i ti on  1 oad  ( i f any ) 
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Variable  Name 


Equipment  Characteristic 


R0FE(IEQ,l-3) 


ROFE( IEQ.4-8) 


I AMTE ( I EQ , 1 ) 

I AMTE ( I EQ , 2 ) 

IAMTE(IEQ,3) 
I AMTE ( I EQ , 4 ) 

IAMTE( IEQ,5) 


Fraction  of  personnel  within  target  area 
killed  by  this  equipment,  for  each  of 
three  personnel  vulnerability  classes 

Fraction  of  equipment  within  target  area 
damaged  by  this  equipment,  for  each  of 
fire  equipment  vulnerability  classes 
IEQCLS  (if  any) 

Number  of  ammunition  type  used  by  this 
equipment 

NumDer  of  rounds  of  ammo  in  a standard 
load  (if  any) 

Rate  of  fire  (for  weapons) 

Number  of  drops  in  a single  pass  (for 
bombs) 

Distance  between  drops 


17)  The  air  movement  m^du^e  contains  logic  to  abort  air  missions  under 
certain  conditions.  .,ie  logic  to  abort  the  mission  is  in  SUBROUTINE 
AIRABORT.  Missions  are  aborted: 


a.  When  a CANCEL  AIR  MISSION  command  is  received  through  the 
command  and  control  subsystem. 

b.  When  meteorological  visibility  falls  below  an  input  minimum 
for  the  applicable  aircraft  type,  i.e.,  VISM<R0ME  (I AC, 7) 
where  IAC  = aircraft  equipment  number. 

18)  When  an  existing  air  mission  is  changed,  the  location  of  the  air- 
craft at  the  time  of  the  change  is  used  as  the  first  of  the  (up  to) 
9 route  points,  and  the  others  are  as  selected  by  the  controller. 
Other  than  this,  processing  is  almost  identical  to  the  crea- 
tion of  a new  air  mission. 

19)  Each  time  step  density  altitude  is  re-computed  from  current 
meteorological  conditions  and  compared  against  the  require- 
ments of  each  air  unit,  considering  current  aircraft  load. 

Aircraft  whose  requirements  exceed  current  density  altitude 
are  attrited. 
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201  when  an  air  unit  runs  out  of  fuel  (this  is  unlikely  consider- 
in'-' extensive  error  checking  during  processing  of  the  event 
notice  creating  or  changing  the  air  mission)  it  becomes 
defunct . 

21)  Air  attacks  are  executed  across  the  width  of  the  target  unit 
regardless  of  the  direction  the  air  unit  happens  to  be  moving 
immediately  before  and  immediately  after  delivery.  The 
geometrical  computation  in  subroutine  FRFD  assumes  this  in 
determining  the  area  of  overlap  between  the  ordnance  lethal 
area  and  the  target  unit's  area. 

5.8  3 Equations 

The  important  tactical  and  physical  mathematical  equations  used  by 
the  Air  Module  chains  are  presented  below: 

5 8.3.1  A I REVENT  Chain 

All  listed  equations  are  in  subroutine  AIREVENT. 

1)  Calculate  density  altitude 

Aircraft  performance  is  significantly  affected  by  the  density  of 
the  air  it  flies  through.  Air  density  is  a function  of  temperature. 
Density  altitude  is  the  altitude  in  a standard  atmosphere  correspond- 
ing to  a particular  value  of  air  density  as  determined  by  ambient 
temperature. 

DNSALT  = (TEMP  - 59.)/5.5  * 304.8 
where 

DNSALT  = density  altitude 

TEMP  = ambient  temperature  in  degrees  Fahrenheit 

2)  Convert  knots  to  meters/minute 

This  is  a straight  conversion  from  knots  (nautical  miles  per 
hour)  to  meters  per  minute. 

IV  = FLOAT ( IV ) * CKNT2MSC  + 5 


where 
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IV  = velocity  in  meters  per  minute 
FLOAT(IV)  = the  floating  point  value  of  the  velocity  in  knots 
CKNT2MSC  = 30.866  = conversion  factor 
3)  Calculate  fuel  consumed  on  a flight  leg,  as  influenced  by  airspeea 

Fuel  consumption  is  a non-linear  function  of  airspeed.  In  order 
to  simplify  the  air  module  an  approximation  was  sibstituted  for  the 
actual  fuel  consumption  curves,  as  affected  by  airspeed.  The  air 
module  uses  a two  piece  linear  approximation  of  fuel  consumption  vs. 
airspeed  with  its  calculations  based  on  input  values  of  fuel  consumption 
at  minimum  speed,  cruise  speed  and  maximum  speed. 

The  fuel  consumed  on  a leg  of  the  flight  is  calculated  by  adding 
together:  (1)  the  amount  consumed  at  the  lowest  airspeed  for  that 

portion  of  the  curve;  and  (2)  the  amount  consumed  as  a result  of 
flying  faster  than  that  airspeed,  calculated  by  linear  interpolation. 


0) 

where 


DF  = 
IV  = 
Ml ,M2  = 

ROME ( IAC,3)  = 
R0ME( I AC, 4)  = 
R0ME( IAC  ,5)  = 
R0FE( IAC,3)  = 
R0FE( IAC ,4 ) 
R0FE( IAC, 5 ) = 
TIME  = 


amount  of  fuel  consumed  to  this  leg 
veloci ty 

variables  set  to  determine  which  portion  of  the 
fuel  consumption  curve  to  use;  Ml  = 3,4;  M2  = 4,5; 
M2  = Ml  + 1 

minimum  aircraft  speed 
cruise  speed 
maximum  aircraft  speed 

fuel  consumption  rate  at  minimum  aircraft  speed 
fuel  consumption  rate  at  cruise  speed 
fuel  consumption  rate  at  maximum  aircraft  speed 
length  of  time  spent  on  this  leg 
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4)  Calculate  pressure  density 

The  pressure  density  calculations  done  in  AIREVENT  are  the  same 
as  those  done  in  the  AIRMOV  chain.  See  AIRMOV  equation  (2)  for  the 
explanation. 

5)  Calculate  maximum  load  aircraft  can  carry 

The  load  carrying  capabilities  of  the  aircraft  are  modeled  as  a 
’linear  function  of  air  density.  The  calculation  of  the  maximum  load 
the  aircraft  can  carry  is  done  as  a linear  interpolation  between  the 
maximum  load  at  best  air  density  and  maximum  load  at  worst  air  density. 

MAXLOAD  = ROME ( IAC , 1 ) + PDFAC  * (R0ME(IAC,6)  - ROME(IAC.l)) 
where 

MAXLOAD  = maximum  load  the  aircraft  can  carry  at  a given  air 
density 

ROME ( IAC , 1 ) = maximum  load  the  aircraft  can  carry  at  the  best 
pressure  density 

R0ME(IAC,6)  = maximum  load  the  aircraft  can  carry  at  the  worst 
pressure  density 

PDFAC  = pressure  density  factor 

6)  Calculate  weight  of  fuel  necessary  to  transport  the  aircraft  load 

This  calculation  is  based  on  the  assumption  that  the  weight 
of  fuel  in  pounds  necessary  to  transport  the  aircraft  load  is  pro- 
portional to  the  weight  of  fuel  necessary  to  transport  the  basic 
ai rcraft. 

DF  = FLOAT(NPDSFUEL)  * DE  * (1  + R0FE( IAC ,6) )/R0ME(  IAC , 1 ) 

where 

DF  = weight  of  fuel  necessary  to  transport  the  aircraft 
load 

NPDSFUEL  = weight  of  fuel  required  for  basic  aircraft  to  fly 
mission 

DE  = weight  of  equipment  to  be  transported 
ROME(IAC.l)  = maximum  weight  of  load  aircraft  can  carry 
R0FE(IAC,6)  = ratio  of  fuel  consumption  at  maximum  and  minimum  load 
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5. 8. 3 . 2 AIRMOV  Chain 

AH  listed  equations  are  in  subroutine  AIREVENT. 
n Convert  Fahrenheit  temperature  to  Kelvin 

TK  = <TF  + 4°)  | + 233 

= (Tp  - 32)  | + 273 

where 

Tp  = temperature  in  degrees  Fahrenheit 

(calculated  by  weather  model) 

Tk  = temperature  in  degrees  Kelvin 

2)  Calculate  air  density  factor 

DFAC  = (DBEST  - DNSTY)/ (DBEST  - DWORST) 

where 

DBEST  = 288/244  = best  air  density  ratio 
DWORST  = 288/322  = worst  air  density  ratio 
DNSTY  = 288/ T,, 

IN 

T^  = temperature  in  degrees  Kelvin 

DFAC  = air  density  factor  = fraction  of  distance  between 
DBEST  and  DWORST  at  which  DNSTY  lies 

3)  Calculate  density  altitude 

DNSALT  = (Tp  - 59)  no- 
where 

Tp  = temperature  in  degrees  Fahrenheit 
(see  equation  1 ) 

DNSALT  = density  altitude 

4)  Calculate  fuel  consumption  factor  for  aircraft  load  and  a it 
density  effects 
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FFACTOR  = (1  + • LFACTR)  (1  + DFAC  • DFACTR) 


where 


LOAD  = current  aircraft  load  in  pounds 
XLOAD  = maximum  aircraft  load  in  pounds 
(input  for  each  aircraft  type) 

LFACTR  = additional  fuel  consumption  at  maximum  load 

fuel  consumption  at  maximum  load  ^ 

fuel  consumption  at  minimum  load 

(input  for  each  aircraft  type) 

DFAC  = air  density  factor  (see  equation  2) 


DFACTR  = 


fuel  consumption  at  worst  air  density 
fuel  consumption  at  best  air  density 


FFACTOR  = fuel  consumption  factor  for  aircraft  load  and  air 
density  effects 

5)  Calculate  aircraft  speed 

V = V±  MIN  (|  DVl,  DT  • ACC) 


where 

V = current  aircraft  speed  in  meters/minute 

DV  = desired  speed  for  this  leg  minus  current  speed 
(desired  speed  is  input  as  part  of  flight  route 
for  each  mission) 

DT  = duration  of  current  movement  period  - nominally  1/4 
minute  (see  equation  18) 

ACC  = maximum  aircraft  acceleration  capability  (input  for 
each  aircraft  type)  in  meters/minute/minute 

||  = absolute  value  function 
MIN  = minimum  value  function 

6)  Calculate  altitude  change 

DZ  = ±MIN  (|AZ|  , DT  - CD) 

7)  Calculate  new  aircraft  altitude 
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Z = Z + DZ 

where 

Z = current  aircraft  altitude  in  meters 

DZ  = altitude  change  this  movement  period  in  meters 

<17  = desired  altitude  for  this  flight  leg  (input  for 
each  mission)  minus  current  altitude 

DT  = duration  of  current  movement  period  - nominally 
1/4  minute  (see  equation  18) 

CD  = maximum  climb/dive  capability  (input  for  each  aircrat 
type)  in  meters/minute 

8;  Calculate  ground  distance  traveled 
DG  = V-  DT 

where 

DG  = ground  distance  traveled  this  movement  period 
V = current  aircraft  ground  speed  (see  equation  5) 

DT  = duration  of  current  movement  period  (see  equation  ’8) 
■j)  Calculate  new  X coordinate 
Xi  =Xi_1  + DG  • COS 
10)  Calculate  new  Y coordinate 

Yi  = Y._1  + DG  • SIN 

where 

X. j  = X coordinate  of  aircraft  at  end  of  movement  period  * 

Y . = Y coordinate  of  aircraft  at  end  of  movement  period  i 

DG  = distance  traveled  over  ground  during  current  movement 
period  (see  equation  7) 

COS  = cosine  of  direction  of  travel  of  air  unit 

SIN  = sine  of  direction  of  travel  of  air  unit 
(see  equations  11  and  12) 


11)  Calculate  cosine  of  direction  of  travel 

COS  = DX/D 

12)  Calculate  sine  of  direction  of  travel 

SIN  = DY/D 

where 

DX  = X coordinate  of  next  air  route  point  minus  X coordinat. 
of  air  route  point  just  reached,  in  meters 

DY  = Same  as  DX,  but  for  Y coordinate 


D DX-  DX  + DY • DY  = distance  between  route  point  just 
reached  and  the  next  route  point,  in  meters 

COS  = cosine  of  direction  of  travel  to  next  route  point 

SIN  = sine  of  direction  of  travel  to  next  route  point 

13)  Calculate  pounds  of  fuel  consumed,  including  aircraft  speed  and 
altitude  change  effects 


DF  = DZ  • UPDN  + (V  - SI ; 


DT 


n • DT 


where 


DZ  = altitude  gained  or  lost  this  movement  period  (see 
equation  6) 

UPDN  = fuel  consumption  factor  for  losing  altitude  if  DZ<0 

or  fuel  consumption  factor  for  gaining  altitude  if  DZ  ' 0 
(input  for  each  aircraft  type) 

V = current  aircraft  speed  (see  equation  5) 

51  = aircraft  minimum  speed  if  V<  cruise  speed,  or  cruise 

speed,  if  V>  cruise  speed 

52  = aircraft  cruise  speed  if  V<  cruise  speed,  or  maximu 

speed,  if  V > cruise  speed 

(minimum,  cruise,  and  maximum  speeds  input  for  each 
aircraft  type)  all  in  meters/minute 

FI  = fuel  consumption  in  pounds/minute  at  speed  SI  (input 
for  each  aircraft  type) 

F2  = same  as  FI  for  speed  S2 

DT  = duration  of  current  movement  period  - nominally  1/4 
minute  (see  equation  18) 
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DF  = fuel  consumption  for  this  movement  period,  excluding 
load  and  air  density  effects 

141  Update  aircraft  fuel  load 

FUEL  = FUEL  - AF 

15)  Update  aircraft  payload 

LOAD  = LOAD  - AF 


where 


FUEL  = current  aircraft  fuel  load  in  pounds 

LOAD  = current  aircraft  load  in  pounds,  including  fuel,  ammo, 
and  equipment 

AF  = pounds  of  -fuel  consumed  this  movement  period  (see 
equation  16) 

16)  Calculate  actual  pounds  of  fuel  consumed 
F = MAX(DF,DT  • F3)  • FFACTOR 


where 


DF  = fuel  consumption  this  movement  period  (see  equation  12 
in  pounds 

DT  = duration  of  this  movement  period  - nominally  1/4  minute 
(see  equation  18) 

F3  = fuel  consumption  at  minimum  speed  (input  for  each  air- 
craft type)  in  pounds/minute 

FFACTOR  = fuel  consumption  factor  for  load  and  density  effects 
(see  equation  4) 

17)  Calculate  time  at  which  end  of  movement  leg  reached 


where 


Tj  = time  at  which  movement  leg  j for  this  time  step  ends 


= time  at  which  movement  leg  j + 1 begins 

DT  = duration  of  this  movement  leg  - nominally  1/4  minute 
(see  equation  18) 


yet  point  each  time  it  is  used  (usiny  the  Change  Air 
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18)  Calculate  time  duration  of  current  movement  leg 
DT  = MIN(TN0M,  Dl/V) 

where 

TNOM  nominal  movement  duration  in  minutes  - set  to  1/4 

O'  = distance  to  next  air  route  point,  at  which  direction 
of  travel  will  change 

V = current  aircraft  speed  (see  equation  5) 

DT  = duration  of  current  movement  leg  in  minutes 
5. 8. 3. 3 AIRM0V2  Chain 

The  subroutine  containing  the  referenced  equation  is  indicated  in 
parentheses . 

1)  Calculate  slant  range  from  aircraft  to  ground  unit  (AIRCAS) 

R =\|  (X  - x)2  + (Y  - y)2  + Z2 

where 

R = slant  range 

(X,Y,Z)  = coordinates  of  aircraft 
(x,y)  = coordinates  of  ground  unit 

2)  Calculate  time  aircraft  exposed  to  fire  of  ground  unit  on  single 
1/4  minute  movement  leg  (AIRCAS) 

TEXP  = (1  - RANDOM  (2  - K) ) (T2  - T1 ) 

TEXP  =0;  K = 1 or  2;  K = 0 

where 

TEXP  = time  exposed 

K = number  of  endpoints  of  movement  leg  at  which  air  unit 
is  within  range  of  and  has  been  detected  by  ground 
unit.  Detection  verdicts  calculated  by  GRNDAJR. 

T2  = time  at  which  aircraft  reached  end  of  movement  leg 
(see  equation  17,  Section  5. 8. 3. 2) 

T1  = time  at  which  aircraft  began  movement  leg 
(see  equation  17,  Section  5. 8. 3. 2) 
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3)  Calculate  number  of  rounds  fired  by  air  defense  weapon  (AIRCAS) 

FIRE  = MIN(TEXP  • ROF  • HUM  • (1  - SIGU),  N ROUNDS) 
where 

TEXP  = time  aircraft  exposed  to  fire,  in  minutes 
(see  equation  2) 

ROF  = rate  of  fire  of  weapon,  in  rounds/minute  - input  for 
each  air  defense  weapon 

HUM  = number  of  pieces  of  equipment  currently  operable  and 
manned  in  ground  unit  - calculated  by  REDIST 

SIGU  = suppression  level  of  ground  unit  - calculated  by  SUPRES 

HROUNDS  = number  of  rounds  of  appropriate  ammunition  type  remain- 
ing in  ground  unit 

MIN  = minimum  value  function 

FIRE  = number  of  rounds  fired 

4)  Update  current  ammo  level  (AIRCAS) 

NROUNDS  = NROUNUS  - FIRE 
where 

NROUNDS  = number  of  rounds  of  applicable  ammo  type  remaining  in 
uni  t 

FIRE  = number  of  rounds  fired  (see  equation  3) 

5)  Update  personnel  vulnerability  classes  for  units  with  air  defense 
weapons  (AIRCAS1) 


PERNVC ■ . ,,  = PERNVC , ■ , + NUMP  * NUME 
i > J > * J » K 

where 


PERNVC.  . k 

• f J » 


= number  of  personnel  in  unit  i with  personnel  vulnera- 
bility class  j and  suppression  mode  K 


NUMP  = number  of  personnel  required  to  man  air  defense  weapon 
(calculated  by  MANNING) 

NUME  = number  of  pieces  of  air  defense  weapon  currently  manned 
in  unit  (calculated  by  REDIST) 


6,  7)  Transform  range  and  deflection  errors  into  X,  Y aim  point  errors 
for  air-delivered  ordnance  (ADW) 


A 
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AIMERX  = RERROR  ■ COS  - DERROR  • SIN 
AIMERY  = RERROR  • SIN  + DERROR  • COS 
where 

RERROR,  DERROR  = normally  distributed  range  and  deflection  errors  for 
this  ordnance  and  delivery  conditions  (standard  devi- 
ation of  errors  calculated  in  equations  20  to  29) 

SIN,  COS  = sine  and  cosine  of  aircraft  flight  path  angle 
(see  equations  11  and  12,  Section  5.8. 3.2) 

AIMtRX,  AIMERY  = X and  Y aim  point  errors 

8,  9)  Calculate  nominal  impact  point  for  air-delivered  ordnance  (ADW) 

XIM  = A I MX  + AIMERX 

YIM  = A I MY  + AIMERY 

where 

AIMX,  AIMY  = X,  Y coordinates  of  aim  point  (input  by  controller) 

AIMERX,  AIMtRY  = calculated  X,  Y aim  point  errors  (see  equations  b,  7) 

XIM,  YIM  = nominal  X,  Y impact  coordinates 

10,  11)  Calculate  individual  aim  points  for  air  ordnance  types  with 
multiple  drops  per  pass  (ADW) 

Xi  = XIM  + (i  - 1 - N/2)  • DELTA  • COS 

Yi  = YIM  + (i  - 1 - N/2)  • DELTA  • SIN 

where 

(XIM,  YIM)  = calculated  nominal  impact  point  (see  equations  8,  9) 

il  = number  of  drops  per  pass  (input  for  each  ordnance  type) 

DELTA  = spacing  of  drops  (input  for  each  equipment  type) 

SIN,  COS  = sine  and  cosine  of  aircraft  flight  path  angle 
(see  equations  11,  12,  Section  5. 8. 3. 2) 

i = drop  number  (1  < i < N) 

(X.,  Y.)  = calculated  individual  ordnance  impact  coordinates 


12-15)  Calculate  boundaries  of  lethal  area  rectangle  for  air  ordnance  (ADU) 
XM1N  = XI  - PTLNTH/2 

XMAX  = XI  + PTLNTH/2 

YMIN  = YI  - PTWDTH/2 

YMAX  = YI  + PTWDTH/2 

where 

XMIN,  XMAX  = minimum  and  maximum  extent  of  lethal  area  in  X direc- 
tion 

YMIN,  YMAX  = minimum  and  maximum  extent  of  lethal  area  in  Y direc- 
tion 

PTLNTH,  PTWDTH  = length  and  width  of  lethal  area  (see  equations  43-46) 

XI,  YI  = coordinates  of  single  air  ordnance  impact  point  (see 
equations  10,  11) 

Note:  (XMIN,  YMIN)  and  (XMAX,  YMAX)  define  the  coordinates  of 

the  "lower  left"  and'upper  right"  corners  of  a rectangle. 

16)  Calculate  personnel  casualties  in  a ground  unit  resulting  from 
air  ordnance  impact  (ADW) 

N 

C = V OVRLAP  • FRAC-  • FIRRATE  • P. 

1=1  1 

where 

OVRLAP  = fraction  of  unit  area  intersected  by  ordnance  lethal 
area,  (calculated  by  FRFD) 

FRAC.  = fraction  of  personnel  in  vulnerability  class  i killed 

1 by  ordnance  when  within  lethal  area  (input  for  each 
ordnance  type  and  vulnerability  class  in  variable  ROFE) 

FIRRATE  = calculated  number  of  rounds  or  pieces  of  ordnance  to 
fall  in  target  area  (calculated  stochastically  in  ADW 
using  input  fire  rate  and  probability  of  hit  for  each 
ordnance  type) 

P^  = number  of  personnel  in  vulnerability  class  i (calcu- 
lated by  ground  fire  module  using  mode  distribution 
vectors) 

N = number  of  personnel  vulnerability  classes  (input) 


Page  5-877 


C = number  of  personnel  casualties  resulting  from  ordnance 
impact 

17)  Calculate  number  of  equipment  casualties  resulting  from  a single 
air  ordnance  impact  (ADD) 

C = OVRLAP  • FIRRATE  ■ FRAC  • T 

where 

OVRLAP,  FIRRATE,  C = (same  as  equation  16) 

FRAC  = fraction  of  equipment  class  1 killed  when  within  lethal 
area  (input  for  each  air  ordnance  and  ground  equipment 
type  in  variable  R0FE( IBETA.4) 

T = total  number  of  pieces  of  this  equipment  type  currer  - . 
i n uni  t. 

18)  Convert  speed  in  meters/minute  to  knots  (ADWDATA) 

V2  = ( VI /I 00)/ 0. 305 

= y ] . — rP—  . 1 

Vl  6000  0.305 


where 


VI  = speed  in  meters/minute 
V2  = speed  in  knots 
0.305  = number  of  meters  in  one  foot 
60  = number  of  minutes  in  one  hour 
6000  = approximate  number  of  feet  in  one  nautical  mile 

19)  Convert  meters  to  feet  (AD1JDATA) 

X2  = X1  ' 07305 

where 

XI  - distance  in  meters 
X2  = distance  in  feet 

20,  21)  Calculate  standard  deviation  of  range  and  deflection  delivery 
errors  for  air  ordnance  classes  1 to  5 (general  purpose  bombs), 
6 to  8 (high  drag  bombs)  and  17  (napalm)  (ADWDATA) 
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RPE  = V (8FT) 2 + (Cl  • SR2/Z) 


DPE  = V(8FT)2  + (C2  • SR)2 


where 

FT  = length  of  time  required  for  ordnance  to  fall  to  ground 
Cl  = input  constant  = 0.0212 
C2  = input  constant  = 0.0184 

SR  = slant  range  to  target  at  ordnance  release  point  (see 
equation  35) 

Z = aircraft  altitude  (see  equation  7 in  Section  5.8. 3.2) 

RPE,  DPE  = standard  deviations  of  range  and  deflection  delivery 
errors 

22,  23)  Same  as  20,  21  except  for  equipment  classes  11  and  12  (2.75  in. 
rockets  and  20  mm  cannon,  respectively)  (ADWDATA) 

RPE  = input  constant  for  each  class 

DPE  = input  constant  for  each  class 

24,  25)  Same  as  20,  21  except  for  equipment  class  13  (CBU-2) (ADWDATA) 
Equations  are  identical  to  20,  21  except: 

Cl  = 0.0163;  C2  = 0.0171 

26,  27)  Same  as  20,  21  except  for  equipment  class  10  (Maverick 
and  other  guided  projectiles)  (ADWDATA) 

RPE  = 0.0 

DPE  = 0.0 

28,  29)  Same  as  20,  21  except  for  equipment  classes  14,  15  (CBU-24  and 
Rockeye) (ADWDATA) 

RPE  = T( IALT,  IVEL)  • C 

DPE  = RPE 


where 


C = input  constant  = 0.674 

T(IALT,  IVEL)  = table  look-up  function  for  altitude  level  IALT  and 

speed  level  IVEL  at  delivery  (see  equations  30  and  31) 
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30,  31)  Calculate  altitude  level  and  speed  level  for  use  in  table  look-up 
functions  (ADWDATA) 

I ALT  = I,  if  | A(  I)  - Z|  <U(J)  - z| 
for  every  J * I 

IVEL  = K,  if  | V(K)  - S | < | V ( L ) - Si 
for  every  L * K 

where 

Z = aircraft  altitude  at  delivery  (s;j»  quation  7 in 
Section  5.8.3. 2) 

S = aircraft  speed  at  delivery  (see  equation  5 in 
Section  5.8. 3. 2) 

A = table  of  "break"  altitudes,  in  feet 
= 300,  500,  750,  1000,  1500,  2000,  3000 
V = table  of  "break"  velocities,  in  knots 
= 250,  350,  400,  450,  500,  600 

Note: 

1 < I <7 
1 < 6 

32)  Calculate  time  required  for  ordnance  to  fall  to  ground  for 
equipment  classes  1 to  5 and  17  (GP  bombs  and  napalm) (ADWDATA) 

FT  = y/Z  ' Z/G 

where 

Z = aircraft  altitude  in  feet  (see  equation  7 in 
Section  5.8. 3. 2) 

G = gravitational  constant 

= 32  ft/sec2 

FT  = fall  time  in  seconds 

33)  Same  as  32  for  equipment  class  13  (CGU-2) (ADWDATA) 

0.54 


A 


FT  = 0.31 (Z) 
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where 

Z = aircraft  altitude  in  feet  (see  equation  7 in 
Section  5.8. 3. 2) 

FT  = fall  time 

34)  Same  as  32  for  equipment  classes  6 to  8 (high  drag  bombs) (ADWDATA) 
FT  = T( IALT,  IVEL,  ITYPE) 

where 

IALT,  IVEL  = altitude  and  velocity  levels  (see  equation  30,  31) 
ITYPE  = high  drag  ordnance  type  (1,  2,  or  3) 

T = table  look-up  function 
FT  = fall  time 

35)  Calculate  aircraft  slant  range  at  ordnance  release  point  for 
equipment  classes  1 to  5,  6 to  8,  13,  and  17  (ADWDATA) 

SR  = \]z  >1  + R>  R 

where 

Z = aircraft  altitude  in  feet 
R = ground  range  in  feet  (see  equations  36  to  38) 

SR  = slant  range  in  feet 

36)  Calculate  ground  range  at  ordnance  release  point  for  equip- 
ment classes  1 to  5 and  17  (GP  bombs  and  napalm)  (ADWDATA) 

R = FT  - V • C 

where 

FT  = time  required  for  ordnance  to  fall  to  ground  (see 
equations  32  and  33) 

V = aircraft  speed  in  knots 

C = input  constant  to  convert  knots  to  ft/sec  = 1.667 
R = ground  range  in  feet 

37)  Same  as  equation  36  for  equipment  classes  6 to  8 (high  drag 
bombs)  (ADWDATA) 


R = T( IALT,  IVEL,  ITYPE) 
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where 

IALT,  IVEL  = altitude  and  velocity  levels  at  release  point  (see 
equations  30  and  31 ) 

1TYPE  * ordnance  type  =1,  2,  or  3 

T = table  look-up  function 

R = ground  range  in  feet 

38)  Same  as  equation  36  for  equipment  class  13  (CBU-2) (ADWDATA) 

R = 61 5(Z)°* 101  + 1 .3  • V - 700 

where 

Z = aircraft  altitude  in  feet 
V = aircraft  speed  in  knots 

39)  Calculate  lethal  area  of  air-delivered  ordnance  for  equip- 
ment classes  1 to  8 and  17  (ADWDATA) 

A = 1 . 0/  ( T-j  ( ITYPE)  - T2(ITYPE)  • ANGLE) 

where 

ITYPE  = ordnance  type  number 
T^,  T2  = table  look-up  functions  of  constant  values 
ANGLE  = ordnance  impact  angle  (see  equations  49  and  50) 

A = lethal  area 

40)  Same  as  equation  39  except  for  equipment  classes  9 to  12 (ADWDATA) 

A = T( ITYPE) 

where 

ITYPE  = ordnance  type  numDer 

T = table  look-up  function  of  constant  values 
A = lethal  area 

41)  Same  as  equation  39  except  for  equipment  class  13  (ADWDATA) 

A = C + 4 • Z 
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where 

C = constant  = 700 
Z = aircraft  altitude  at  delivery 
A = lethal  area 

42)  Same  as  equation  39  except  for  equipment  class  15(ADWDATA) 

A = T( I ANGLE) 

where 

T = table  look-up  function  of  constant  values. 

IANGLE  = [(ANGLE  + 14)/15] 

ANGLE  = ordnance  impact  angle  in  degrees  (see  equations  49,  50) 
= greatest  integer  function 

43,  44)  Calculate  length  and  width  of  lethal  area  on  ground,  for  air- 

delivered  ordnance  with  equipment  classes  1 to  13  and  lb(ADWDATA) 

PTLNTH  = Va/3 
PTWDTH  * 3 • PTLNTH 
where 

A = lethal  area  (see  equations  39  to  42) 

PTLNTH  = effective  lethal  length  to  use  for  casualty 
PTWDTH  = effective  lethal  width  to  use  for  casualty  computations 
Note:  PTLNTH  • PTWDTH  = = A 

45,  46)  Same  as  equations  43,  44  except  for  equipment  classes  14  and  17 
(ADWDATA) 

PTLNTH  = T-j  ( ITYPE) 

PTWDTH  = T2( ITYPE) 
where 

ITYPE  = ordnance  type 

T^ , T^  = table  look-up  functions  of  constant  values 
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PTLNTH,  PTWDTH  = effective  lengtn  and  width  to  use  in  casualty  computa- 
tions 

47,  48)  Calculate  vertical  and  horizontal  velocity  components  of  ordnance 
at  impact  for  equipment  classes  1 to  5,  and  17  (ADWDATA) 

VH  = V • COSD 

VZ  = V • SIIMD  + G • FT 


VH,  VZ  = horizontal  and  vertical  components  of  ordnance  velocity 
at  impact 

V = aircraft  speed  at  delivery  (input  by  controller) 

SIND,  COSD  = sine  and  cosine  of  dive  angle  (assumed  to  be  30°) 

2 

G = gravitational  constant  = 32  ft/sec 

FT  = fall  time  of  ordnance  (see  equations  32  to  34) 

49)  Calculate  impact  angle  for  ai r-del i vered  ordnance  with  equip- 
ment classes  1 to  5,  and  17 (ADWDATA) 

ANGLE  = ATAN( VZ/VH)  . C 


where 

VZ,  VH  = vertical  and  horizontal  components  of  ordnance  velocity 
at  impact  (see  equations  47,  48) 

ATAN  = inverse  tangent  function 

C = constant  to  convert  radians  to  degrees 

ANGLE  = impact  angle  in  degrees 

50)  Same  as  equation  49  except  for  equipment  classes  6 to  8,  and  IF 
(ADWDATA) 

ANGLE  = T(IALT,IVEL,ITYPE) 
where 


IALT,  I VEL 

ITYPE 

T 

ANGLE 


altitude  and  velocity  levels  of  aircraft  at  delivery 
( see  equations  30,  31 ) 

ordnance  type 

table  look-up  function  of  constant  values 
impact  angle  in  degrees 


Page  5-884 


1 


51)  I END  = FIRRATE  * IAMTE( IBETA.4)  + .01  (ADW) 

Total  number  of  projectiles  released  (IEND)  = number  released 
on  one  drop  (FIRRATE)  * number  of  drops  + a factor  insuring  correct 
floating  to  integer  conversion. 

52-55)  IXYX(l)  = I X Y (11,1)  + 0.5  * IW  (ADW) 

I X YX ( 2 ) = IXY(II.l)  - 0.5  * IW 

IXYY(l)  = I X Y ( 11,2)  + 0.5  * ID 

I X Y Y ( 2 ) = IXY ( 1 1 ,2)  - 0.5  * ID 

where 

IW  = IUWID(II)  - unit  II 's  width 
ID  = IUDEP(II)  - unit's  depth 

Half  the  width  (depth)  is  added  and  subtracted  to  the  unit's 
center  point  X-(Y-)  coordinate  to  yield  the  X-(Y-)  boundaries  of 
the  target  unit. 

56)  IDCAS  = MIN(R0FE( I BETA , 1 ) * IEND,  PERNVC ( 11,1 ,1 ) + 

PERNVC ( 1 1 ,2,1 ) ) (ADW) 

Personnel  casualties  resulting  from  a "hard  bunker"  attack 
equals  the  number  killed  per  projectile  times  the  number  of 
projectiles,  with  an  upper  bound  of  the  total  number  of  personnel 
in  vulnerability  classes  1 and  2 of  the  target  unit  II. 
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5.9  COMMAND  AND  CONTROL  MODULE 

The  CATTS  Command  and  Control  Module  controls  a diverse  variety  of 
events  and  actions,  which  allows  the  controllers  to  input  to  the  simula- 
tion the  commands  and  actions  of  everyone,  from  individual  squad  leaders 
to  Mother  Nature.  Thus,  in  addition  to  the  "traditional"  command  and  con- 
trol functions  of  maneuver,  fire,  and  tasking  organization,  the  CATTS  com- 
mand and  control  module  controls  in  the  same  manner  other  things,  not 
usually  thought  of  as  command  and  control.  These  include  weather,  resupply, 
control  measures,  pre-constructed  alert  messages,  unit  size,  unit  deactiva- 
tion (instant  removal  from  a simulation  run),  air  missions,  air  defense,  and 
preplanned  missions  (a  collection  of  any  of  the  above  control  actions  which 
can  be  repeatedly  made  to  occur  at  any  time  during  the  simulation). 

Maneuver,  fire,  and  tasking  organization  command  and  control  instruc- 
tions are  input  to  the  simulation  using  2 different  methods:  1)  The  events 

processor,  and  2)  The  command  and  control  decision  tables  (the  old  MAFIA  V 
command  and  control).  The  other  command  and  control  items  (weather,  resupply, 
control  measures,  pre-constructed  alert  messages,  unit  size,  unit  deactiva- 
tion, air  missions,  air  defense,  and  preplanned  missions)  can  only  be  input 
and  activated  via  the  events  processor.  The  events  processor  interactively 
accepts  command  and  control  during  a game.  The  controllers  use  the  command 
and  control  switches  on  the  control  panel,  the  graf  pens  and  the  menus  on 
the  lower  1/3  of  the  television  monitors  to  input  command  and  control  at  the 
initialization  of  a game  and  during  a game. 

Foreground  software  drives  the  menus,  the  control  panel,  and  the  graf 
pens,  and  converts  the  command  and  control  to  a 64  word  event  notice1  which 
is  passed  via  a disk  file  to  the  background  command  and  control  software  for 
processing.  This  foreground  software  is  described  in  detail  in  Section  4.3 
of  the  CATTS  Trainer  Programming  Report,  NAVTRAEQUIPCEN  73-C-01 56-A005.  An 
overview  of  the  interfaces  between  the  math  model  and  the  foreground  soft- 
ware is  presented  in  Section  3.3  of  the  same  document.  The  interested 
reader  is  strongly  encouraged  to  refer  to  this  document.  A specific  dis- 
cussion of  the  foreground  software  is  not  presented  in  this  User's  Manual. 

Note  1 - Two  formats  for  the  64  word  event  notices  exist,  a foreground  and 
background  format.  These  are  shown  in  Figure  5-138. 


Figure  5-138.  Foreground  to  Background  Event  Notice  Conversion 
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The  event  notices  are  passed  via  disk  file  in  order  to  decouple  fore- 
ground software  and  background  software,  and  to  preserve  data  integrity. 

For  example,  it  would  be  possible  for  the  foreground  software  to  just  go 
ahead  and  change  model  variables  directly,  rather  than  go  through  the 
seemingly  unnecessary  complication  of  passing  the  data  through  disk  files. 
However,  in  order  to  have  the  capability  to  schedule  events  to  occur  in 
the  future  a disk  file  is  necessary  anyway.  Additionally,  the  foreground 
software  is  severely  core-constrained,  making  it  more  attractive  to 
perform  the  extensive  consistency  checking  needed  in  the  background,  rather 
than  the  foreground.  These  reasons  would  probably  be  sufficient  to  dictate 
the  use  of  disk  files.  There  is  an  additional  issue,  however,  which  makes 
the  use  of  disk  files  imperative:  data  integrity.  Two  very  simple 

examples  will  be  given  to  demonstrate  the  importance  of  this  issue.  Both 
of  these  examples  will  assume  that  the  foreground  menu  software  changes 
math  model  variables  directly,  rather  than  communicating  through  disk  files. 

Example  1.  Suppose  a controller  resupplied  unit  1 /A/2 - 77  with  ten 
more  men.  Suppose,  moreover,  that  this  occurred  in  the 
instant  that  the  math  model  itself  was  updating  personnel 
levels  for  that  unit  to  account  for  casualties.  It  is 
quite  possible,  in  this  case,  for  the  math  model  to  store 
the  new,  calculated  personnel  level  on  top  of  the  level 
set  by  the  foreground,  with  the  net  effect  that  the  ten 
men  never  show  up  in  unit  l/A/77. 

Example  2.  Suppose  a controller  resupplied  all  vehicles  out  of  unit 
1 /A/2- 77 . Suppose,  further,  that  this  occurred  during  a 
calculation  involving  a division  by  the  number  of  vehicles 
in  the  unit.  Such  divisions  normally  have  a check  for 
zero  divisor  to  protect  against  division  by  zero.  However, 
suppose  the  foreground  removed  the  vehicles  after  the 
check  for  zero,  but  before  the  division.  The  result  is 
that  the  CATTS  exercise  would  be  prematurely  and  abnormally 
terminated  when  the  division  by  zero  took  place. 
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These  examples  may  seem  farfetched;  however,  the  reader  must  remember 
two  things.  One  is  that  a large  number  of  command  and  control  events  are 
executed  during  an  exercise,  and  the  other  is  that  either  of  the  two 
results  in  the  examples  is  completely  unacceptable  and  to  be  avoided  at 
all  costs. 

Non-interactive  command  and  control  may  be  input  before  a game  starts 
via  2 methods:  1)  Namelist  cards  containing  64  word  event  notices^  in 

the  run  deck  or,  2)  The  prescheduled  e^ent  disk  file.  The  prescheduled 
events  file  can  be  filled  by  the  user  by:  1)  Copying  punched  cards  con- 
taining 64  word  event  notices^  to  tne  file  using  Xerox  RADEDIT  or 

2)  Executing  a procedure  wnich  saves  command  and  control  input  during 
initialization  of  a game  as  64  word  event  notices^  on  the  prescheduled 
event  file  (see  Appendix  B of  the  Data  Base/Operations  Manual  for  the 

details).  All  of  the  command  and  control  input  to  the  simulation  via  the 

events  processor  is  activated  at  the  model  time  input  with  each  command 
and  control  event.  Thus,  events  can  be  scheduled  to  occur  in  the  future 
as  well  as  immediately.  However,  the  only  thing  that  activates  or  triggers 
events  input  via  the  events  processor  is  model  time.  This  is  different 
from  what  triggers  the  command  and  control  input  via  the  decision  tables 
(see  Table  5-63,  Change  of  State  Criteria,  in  Section  5. 9. 2.1)  for  a list 
of  what  triggers  changes  of  op  states. 

The  command  and  control  decision  tables  are  input  and  stored  on  the 
data  base  scenario  file  (like  file  NBIG).  They  are  read  in  during  initial- 
ization and  thus  cannot  be  changed  during  the  game.  The  information  in  the 
condition  word  of  each  table  is  searched  by  the  math  model  each  minute  (if 
events  during  tne  minute  warrant  - not  all  of  the  tables  are  searched  each 
minute),  and  if  a match  is  found,  then  the  command  and  control  contained 
in  the  associated  action  word  of  the  table  is  activated.  The  method  of 
cnanging  the  data  in  these  tables  is  contained  in  the  Data  Base/Operations 
Manual ■ A more  detailed  description  of  the  tables  and  their  operation  is 
contained  in  Section  5.9.3. 


Note  1 - See  footnote  1 on  page  5-885. 
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Obviously,  command  and  control  input  via  the  events  processor  and  the 
decision  tables  can  conflict  with  each  other.  However,  a maneuver  command 
given  to  a unit  via  the  maneuver  menu  cannot  be  changed  by  any  of  the 
decision  table  command  and  control.  The  tasking  organization  control 
afforded  by  the  decision  tables  is  very  weak  and  unwieldy,  but  it  could 
counteract  tasking  organization  input  via  the  menus. 

The  capability  afforded  by  the  decision  tables  is  so  powerful  and 
so  flexible  that  the  user  can  tremendously  improve  the  realism  of  the 
simulation  by  implementing  changes  and  additions.  (This  is  particularly 
true  because  the  tables  are  delivered  to  Fort  Leavenworth  contained  only 
entries  of  least  possible  number  and  complexity).  However,  the  great 
flexibility  provided  makes  the  task  of  predicting  specific  outcomes,  or 
conflicts  with  other  data  entries,  nearly  impossible.  TRW's  experience 
is  that  the  data  tables  must  be  modi f i ed  with  care  and  "tuned"  as 
experience  reveals  omissions  or  conflicts. 

In  addition,  the  simulator  is  designed  so  that  command  and  control 
communication  with  a unit  via  the  menus  is  temporarily  lost  when  that 
unit's  command  post  is  destroyed.  When  this  destruction  happens,  all 
command  and  control  input  for  the  units  which  are  controlled  by  the 
devastated  command  post  is  ignored  for  NODEADCP  minutes.  This  decision 
is  made  by  the  ISDEADCO  subprogram  based  on  values  stored  in  table 
IMDEADCP  by  subroutine  STEP.  Assumptions  made  by  this  subroutine  (which 
are  unnecessary  and  easily  removed)  prevent  the  occurrent  of  communi cat  ions 
loss  more  than  once  per  unit  per  simulation. 

5.9.1  Events  Submodule 

5.9. 1 . 1 Operation 

Figure  5-139  shows  all  the  parts  of  the  events  submodule  and  the 
general  information  flow.  Figures  5-140  and  5-141  show  the  subroutine 
linkages,  and  Table  5-60  gives  a orief  description  of  each  subroutine 
with  major  inputs  and  outputs.  During  initialization,  all  the  events 
from  the  prescheduled  events  file  and  the  run  deck  are  read  in  by  sub- 
routine INPUT  and  written  to  the  background  events  file  by  subroutine 
PEVENT.  Also,  if  SSW3  is  on  so  that  the  data  base  scenario  file  (NBIG, 
for  example)  is  being  read  in,  the  preplanned  mission  events  are  written 
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Figure  5-139.  Events  Submodule  Operation 
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Table  5-60.  Events  Submodule  Subroutine  Descriptions  (Continued) 
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Table  5-60.  Events  Submodule  Subroutine  Descriptions  (Continued) 
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Table  5-60.  Events  Submodule  Subroutine  Descriptions  (Continued) 
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5-60.  Events  Submodule  Subroutine  Descriptions  (Continued) 
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1 Output:  INEVNT  I - (See  subroutine  EVENTS). 

NEXTEV  | 
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NPPREC(I)  - Total  number  of  events  com- 
prising preplanned  mission 
number  1. 


Subroutine  i Description  Principal  Inputs/Outputs 
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TOTEQU  - (See  subroutine  AIREVENT). 
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INEVNT  I - (See  subroutine  EVENTS). 

NEXTEV  ) 

ITNE  - (See  subroutine  PEVENT). 
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IFOUND  - Flag  indicating  whether  storage 

was  successful. 
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to  the  preplanned  mission  file  (PBIG,  for  example)  by  subroutine  PPLANINP. 
Immediately  after  each  of  the  pauses  during  initialization,  where  the  halt 
light  comes  on  and  the  RAM  alerts  come  up,  the  foreground  events  file  is 
read  by  subroutine  FORSIG  and  all  the  events  on  it  are  added  to  the  back- 
ground events  file,  again  by  subroutine  PEVENT.  Then,  the  events  scheduled 
for  minute  zero  are  read  from  the  background  events  file  and  executed. 

Thus,  no  events  are  executed  until  after  the  first  halt  during  initializa- 
tion. During  the  running  of  the  game,  the  foreground  events  file  is  read 
once  a model  minute,  and  the  format  converted,  and  then  the  events  are 
immediately  written  to  the  background  events  file.  After  the  foreground 
events  file  is  empty,  the  events  scheduled  for  the  current  minute  are 
read  from  the  background  events  file  and  executed. 

The  logic  flow  for  the  principal  routines  of  the  Events  Submodule  is 
presented  as  Figures  5-142,  5-143,  and  5-144  (subroutines  FORSIG,  EVENTS,  and 
PPEVENT,  respectively).  Some  routines  not  flowcharted  are  strai ghtforward. 
PEVENT  does  the  bookkeeping  necessary  to  maintain  the  event  list  table, 
INEVENT,  when  new  events  are  added  to  the  background  events  file,  and  also 
writes  the  new  event  on  the  file.  REVENT  perforins  a similar  function  when 
events  are  deleted  - however,  since  there  is  no  menu  in  CATTS  for  deleting 
scheduled  events,  subroutine  REVENT  is  never  executed  during  the  simulation, 
and  could  be  omitted  entirely  with  no  ill  effect.  PREVENT  prints  event 
notices  when  a print  flag  is  turned  on  ( 1 0 1 N TRVL (IS)  > 9).  It  also  writes 
the  events  processed  during  initialization  to  F : 50  to  enable  the  user  to 
duplicate  initial  conditions  precisely  during  later  exercises,  if  desired 
(when  I OINTRVL ( IS ) > 5). 

The  Events  Submodule  is  discussed  at  length  in  the  CATTS  Trainer 
Programming  Report,  Section  5.9,  pages  5-503  through  5-600.  In  particular, 
that  document  contains  detailed  descriptions  of  the  operation  of  each 
event  processor  (such  as  subroutine  AIREVENT)  which  are  not  duplicated 
in  this  User1 s Manual . 

The  command  and  control  menus  may  be  used  to  place  events  on  the 
foreground  events  file  any  time  during  initialization  or  the  running  of 
the  game  (see  Operators  Manual  for  specific  operation  of  command  and 
control  console  buttons  and  menus).  If  at  any  time  (during  initial izati on 
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ENTER 


CAL  4,9  TO 
OBTAIN  POINTER 
TO  NEXT  EVENT 
ON  FOREGROUND 
EVENTS  FILE 


READ  FOREGROUND 
EVENTS  FILE 
F : 25 


CALL  EVENTS 
TO  PROCESS  ALL 
EVENTS  SCHEDULED! 
FOR  THIS  TIME 


CAL  4,5  TO 
TELL  FOREGROUND  I 
A TIMESTEP 
HAS  OCCURRED 


NO  ^ OINTRVL(IS) 


I 


EXIT 


CALL  PREVENT  TO 
PRINT  EVENT  IF  | 
|FLAG  SET,  ALSO  TO 
(SAVE  ON  DISK  FILE 


CALL  REVENT  TO 
DELEGATE  EVENT 
FROM 

BACKGROUND  FILE 


I CALL  PEVENT 
TO  ADD  EVENT  TO 
BACKGROUND  FILL 


STORE  NEW 
UNIT  SIZE 
AND  DIRECTION 
FACED 

I 

, HA$ 

lNIT!ALI-\ 
^ ZATION  BEEN 

XCOMPLETED?/' 

\ / 

\ z' 

'l  NO 


YES 


l 


CONVERT  TO 
BACKGROUND 
FORj  IAT 


STORE  NEW  X,  Y 
COORDINATES  AND 
RECALCULATE 
TERRAIN  BLOCK 


Figure  5-142.  Logic  flow  of  Subroutine  FORSIG 
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or  during  a game),  a preplanned  mission  event  is  executed,  the  actual 
events  to  be  executed  are  read  from  the  preplanned  mission  file  rather 
than  the  background  events  file,  although  the  preplanned  mission  event 
itself  is  kept  on  the  background  events  file. 

Two  tables  keep  track  of  the  events  on  the  background  events  file;  the 
Event  Indicator  Table  and  the  Type-Subtype  Table.  The  Event  Indicator  Table 
and  the  Type-Subtype  Table  are  each  250  words  long  (thus,  a maximum  of  250 
events  may  be  in  the  Events  File  at  any  one  time,  even  though  the  file  is 
large  enough  for  256).  Once  an  event  occurs,  the  space  occupied  by  the  data 
for  this  event  becomes  available  for  use  by  another  event.  The  contents  of 
these  two  tables  are  shown  in  Figure  5-145.  The  Event  Indicator  Table  con- 
tains in  the  first  half  of  each  word,  the  time  (in  minutes)  at  which  the 
event  will  occur.  The  second  half  of  each  word  contains  the  event  number 
(1-250)  of  the  succeeding  event.  If  this  event  is  the  last  scheduled  event 
to  occur,  the  event  number  of  the  succeeding  event  is  zero.  This  table  is 
added  to  every  time  an  event  is  written  to  the  background  events  file,  and 
when  an  event  is  read  from  the  background  events  file,  the  entry  corres- 
ponding to  the  event  is  blanked  out  for  use  by  newly  input  events.  The 
table  is  used  by  the  events  submodule  to  find  on  disk  the  proper  events  tu 
execute  during  the  current  minute.  Thus,  the  model  knows  which  events  are 
to  occur  in  a given  minute,  and  the  order  of  the  events  on  the  background 
events  disk  file.  It  knows  this  by  using  the  core  stored  Event  Indicator 
Table.  The  Type-Subtype  Table  contains  in  the  first  half  of  each  word  the 
event  type,  and  in  the  second  half  of  each  word  the  event  subtype.  This 
table  was  intended  to  allow  the  deletion  of  events  from  the  background  events 
file  before  the  events  occurred.  This  capability  was  never  added  to  the  menus 
as  was,  at  one  time,  planned.  This  was  due  to  problems  of  displaying  the  cur- 
rent contents  of  the  background  events  file  in  a meaningful  manner,  and  the 
fact  that  controllers  can  override  old  events  by  putting  in  a countermandi ng 
event.  However,  the  capability  still  exists  in  the  module,  and  the  user  may 
at  some  future  date  wish  to  make  use  of  it.  If  so,  the  following  information 
will  be  helpful.  The  routine  to  delete  events  (REVtNT)  from  the  background 
events  file  should  be  called  whenever  a scheduled  event  on  the  file  has  not 
yet  occurred.  The  routine  is  enterred  with  the  type  (IT1)  and  subtype  (IT2) 
of  the  event(s)  to  be  deleted,  a time  (ITM),  and  an  indicator  (IND)  which  is 
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equal  to  -1,  0,  or  +1.  The  meaning  of  the  indicator  is  as  follows:  if  IND 

equals  -1,  delete  all  events  of  the  given  type  and  subtype  which  are  scheduled 
to  occur  prior  to  or  at  time  T;  if  IND  equals  0,  delete  all  events  of  the  given 
type  or  subtype  which  are  scheduled  to  occur  at  time  T;  and  if  IND  equals  +1, 
delete  all  events  of  the  given  type  and  subtype  which  are  scheduled  to  occur 
after  time  T.  Events  are  deleted  by  merely  modifying  the  appropriate  entry 
in  the  Event  Indicator  Table. 

Taole  5-61  shows  the  various  event  types,  a brief  description,  and  the 
subroutine  which  is  called  by  the  event  submodule  to  process  each  of  the  event 
types  and  make  them  occur. 

The  formats  c c the  events  varies  slightly  depending  on  the  residence 
(which  of  the  files  or  cards)  contains  the  event  However,  the  exact  same 
i information  is  contained  in  all  the  events,  by  type.  The  specific  contents 

of  each  event  type,  by  type,  will  be  covered  in  the  succeeding  pages.  In 
general,  the  events  contain  a time  in  minutes  at  which  they  are  to  occur, 
the  instructor  ft  of  the  instructor  console  that  entered  the  event  (1,  2,  or 
3),  and  63  other  information  words  whose  content  varies  with  the  event  type. 

The  format  detailed  on  the  following  pages  is  the  form  that  the  events  have 
on  the  background  events  file  and  the  preplanned  mission  file.  Notice  that 
no  time  is  needed  in  this  form  since  the  Event  Indicator  Table  keeps  track 
of  the  time  on  the  background  events  file  and  variables  IPPREC  (starting 
record  number)  and  NPPREC  (#  of  records  in  the  selected  preplanned  mission) 
allow  the  proper  events  to  be  read  in  whenever  a preplanned  mission  is  to 
be  executed.  The  format  on  the  foreground  events  file  is  the  same  except 
the  instructor  # and  the  occurrence  time  are  stored  in  prefixed  words  1 & 

2 respectively,  and  then  foreground  word  3 contains  the  same  data  shown  as 
word  1,  word  4 contains  the  same  data  shown  as  word  2,  etc.  The  format  of 
the  events  on  the  prescheduled  events  file  and  in  the  card  run  deck  are 
identical  and  are  in  namelist  form.  The  time  of  occurrence  is  in  variable 
ITMEVE,  and  the  64  data  words  are  variable  IVUT,  and  they  correspond  exactly 
word  for  word  with  64  words  shown.  The  examples  shown  with  each  event  type 
will  be  in  this  format,  since  this  is  the  format  the  user  must  use  to  input  ■> 
events  via  punched  cards.  Debug  printout  of  both  the  foreground  and  back- 
ground form  can  be  obtained  using  namel istable  array  IOINTRVL( 1 5) . A value 
of  zero  means  no  debug  printout,  1-5  means  print  background  format  when 
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Table  5-61 . Event  Types 


tvent  Notice 
Type 


Description 

j 

Event  Notice 
Processor 

Weather 

WETHRC 

Resupply 

RESUPPLY 

Control  Measures 

CONTMS 

SPLIT  UNIT  (NO  MENU) 

CRCLIC 

Generate  Alert  Message 

ALNUALRT 

Change  Unit  Location 

UNLOCATE 

Unit  Deactivation 

ACTIVATE 

Air  Mission 

AI REVENT 

Ground  Maneuver 

MANEUVER 

Ground  Fire 

FIREVNT 

(Not  Used) 
(Not  Used) 
(Not  Used) 


Air  Defense 
Preplanned  Mission 
Task  Organization 


AIRDEVNT 

PREPLAN 

TASKURG 


Page  5-935 


I 


event  is  activated,  >5  means  print  background  format  when  event  is  activated 

O 

and  print  in  foreground  format  when  the  event  is  received  from  foreground 
, and  ^9  means  print  background  format  when  event  is  activated,  print  in 
foreground  format  when  event  is  received  from  foreground,  and  print  some 
additional  event  debug  printout. 

The  following  show  the  events  structure  for  each  type,  an  example 
event  of  the  type  in  namelist  form,  and  a description  of  wnat  the  example 
event  wil 1 do. 


Note  2 - The  foreground  uses  the  area  where  the  event  notices  are  constructed 
as  a scratch  area  to  aid  in  construction  of  event  notices.  Thus, 
spurious  numbers  may  appear  in  unused  (by  background)  portions  of 
event  notices.  Since  they  are  ignored  by  the  background,  these 
numbers  don't  interfere  with  the  operation  of  the  events  . rocessor. 


r 


EVENT  TYPE  1 - Weather 
SUBEVENT  TYPE  1 


Word 


Contents 


Event  Type  (=1 ) 

Subevent  type  (=1) 

New  Global  Weather  Class 
Not  Used 
Instructor  # 
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SAMPLE  WEATHER  EVENT 


ITMEVE  = 4, 
IVDT(I)  = 1, 

I VDT ( 2 ) = 1, 

I VDT ( 3 ) = 2, 
IVDT(64)  = 1, 


WEATHER  EVENT  DESCRIPTION 

At  4 minutes  into  the  game,  the  weather  class  will  be  changed  to 
2(clear) . 


j 


EVtNT  TYPE  2 - Resupply 
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Word 

1 

2 

3 

4 

5 

6 
7 


8 

y 


10 


Contents 

Event  Type  (=2) 

Subevent  Type  1 = standard  units,  2 = of  basic  load 

Unit  Number  of  Recipient 

Unit  Number  of  Donor 

Number  of  CO's  to  be  Transferred 

Number  of  Officer  to  be  Transferred 

Number  of  Enlisted  Men  in  Leadership  Positions  to  be 
Transferred 

Number  of  Enlisted  Men  to  be  Transferred 

Number  of  Equipment  Resupplies 

First  Equipment  Resupply  Word 
Resupply  Word: 


23 

24 

25 


38 

39 
4U 
41 
64 


Equipment  Type  j Amount  Transferred 


Fourteenth  Equipment  Resupply  Word 

Number  of  Ammo  Resupplies 

First  Ammo  Resupply  Word 
Ammo  Resupply  Word 


Ammo  Type 


Amount  Transferred 


Fourteenth  Ammo  Resupply  Word 
Amount  of  Gasoline  Transferred 
Amount  of  Diesel  Transferred 
Amount  of  Air  Fuel  Transferred 
Instructor 
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SAMPLE  RESUPPLY  EVENT 

ITMEVL  = 0, 

I VDT  = 2,  1,  20,  27,  0,  1,  4,  7,  1,  655364,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  1,  655520,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  2, 


RESUPPLY  EVENT  DESCRIPTION 

At  time  0,  the  following  will  be  transferred  from  unit  ?27  to  unit 

#20: 

1 officer 

4 enlisted  leaders  (NCO's) 

7 enl i sted  men 

4 equipment  type  10  (T-62  tanks) 

160  ammo  type  10  (115  MM  shells) 


EVtWT  TYPE  3 - Control  Measures 
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Word  Contents 
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SAMPLE.  CONTROL  MEASURE  EVENT 


ITMEVE  = 0, 

IVOT  =3,  1,  17,  1,  1,  57770,  25572,  59309,  25594, 

-1,  -1,  -1,  -1,  -1,  -1,  -1,  -1,  -1,  -1,  -1,  -1, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  2, 


CONTROL  MEASURE  EVENT  DESCRIPTION 


At  time  0,  a line  of  type  17  (route  of  march)  wil 
will  be  a red  control  measure,  associated  with  unit  -1 
It  will  go  from  X,Y  57770,  25572  to  59309,  25594. 

SECOND  SAMPLE  CONTROL  MEASURE  EVENT 


ITMEVE  = 10, 
IVDT(l)  = 3, 

I VDT ( 2 ) = 2, 

I VDT ( 3 ) = 4, 

I VDT ( 64 ) = 3, 


SECOND  CONTROL  MEASURE  EVENT  DESCRIPTION 


At  10  minutes 
slot  (4th)  then  is 


into  the  game,  control  measure  ?4  w 
available  for  new  control  measures. 


0,  0,  0,  0,  0,  0,  0,  0,  0, 


be  created.  It 
(for  si zt  purposes) . 


ill  be  deleted.  This 
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EVENT  TYPE  4 - Create  DLIC's  (Detachments  Left  in  Contact) 

Note:  No  Menu  Currently  Exists  for  this  Type  of  Event,  and  the  CATTS 

model  has  been  modified  to  ignore  this  Type  of  Event. 

Word  Contents 

1 Event  Type  (=4) 

2 Event  Subtype  (=1 ) 

3 Unit  Number  of  First  Unit  to  be  Broken  up  to  Create  First  DLIC 

4 Unit  Number  of  First  Dummy  Unit  to  be  come  First  DLIC 

5 Fraction  of  Personnel  to  be  put  in  First  DLIC  (Floating  Point 

Number) 

6 Fraction  of  Crew  Served  Equipment  to  be  put  in  First  DLIC 
(Floating  Point  Number) 


39  Unit  Number  of  Tenth  Unit  to  be  Broken  up  to  Create  Tenth  DLIC 

40  Unit  Number  of  Tenth  Dummy  Unit  to  become  Tenth  DLIC 

41  Fraction  of  Personnel  to  be  put  in  Tenth  DLIC  (Floating  Point 

Number) 

42  Fraction  of  Crew  Served  Equipment  to  be  put  in  Tenth  DLIC 
(Floating  Point  Number) 

43  - 63  Not  Used 

64  Instructor  # 


1 
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No  sample  for  event  type  4 is  given 
as  this  capability  has  never  been  used. 
The  existing  code  in  subroutine  CRDLIC 
has  never  been  checked  out  and  has  been 
removed  from  the  most  recent  versions 
of  CATTS. 
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EVENT  TYPE  5 - Generate  Alert  Message 


Jord  Contents 

1 Event  Type  (=5) 

2 Routing: 


3 


First  Word  of  Message 


1 = INS  1 

2 = INS  2 

3 = INS  3 

4 = INS  1 & 3 

5 = INS  2 & 3 

6 = INS  1 & 2 

7 = INS  1 , 2,  & 3 


30 

64 


. (2  lines  of  72  characters  each)^ 
Last  Word  of  Message 
Instructor  # 


Note  1:  See  problem  report  #335  (only  one  line  is  output  correctly) 
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SAMPLE  GENERATE  ALERT  MESSAGE  EVENT 

ITMEVE  = 0, 

I VUT  = 5,  1,  -472259008,  -488054045,  -975904192, 

-942024988,  -680836927,  1088866518,  -741087168, 

-689515067,  -1002380572,  -1025324604, 

-910042648,  1087817280,  -472259008, 

-908737717,  1799411673,  -974993963,  4 

-471703488,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  1, 

★ 

ITMEVE  = 0, 

I VDT  = 5,  1,  -1052712221,  -690362304,  -691650349, 

-689584789,  1086440677,  -975838236,  -641373376, 

-1042955200,  -473572903,  -909978683,  1088864729, 

455144000,  1549556800,  -960118079,  1086838483, 

-1002415012,  1547714624,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  1 , 

GENERATE  ALERT  MESSAGE  EVENT  DESCRIPTION 

At  time  0,  the  following  2 alert  messages  will  appear  on  the  Super 
Bee  terminal  at  console  #1. 

TRW  SYSTEMS  GROUP,  A WHOLLY  OWNED  SUSIDIARY  OF  TRW  INC.,  PRESENTS  - 
A STORY  OF  LOVE,  ADVENTURE,  AND  TERRIBLE  WAR  ***  FEBA  GOLD  *** 

The  "***  FEBA  GOLD  ***"  portion  of  the  second  message  will  blink  in 
reverse  background  (See  Super  Bee  Manual ) . 


Page  5-946 


r 


EVENT  TYPE  6 - Relocate  Units 

Word  Contents 

1 Event  Type  (=6) 

2 Unit  Number 

3 SINE  of  Direction  that  Unit  will  Face 

4 Unit's  New  X Coordinate 

5 Unit's  New  Y Coordinate 

6 COSINE  of  Direction  That  Unit  Will  Face 

i 7 New  Unit  Depth 

8 New  Unit  Width 

64  Instructor  # 
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SAMPLE  RELOCATE  UNIT  EVENT 

ITMEVE  = 0, 

IVDT  = 6,  87,  1077346607,  65650,  18600,  -1090127198, 

50,  300,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  1, 

★ 

RELOCATE  UNIT  EVENT  DESCRIPTION 

At  time  0,  unit  #87  will  be  relocated  to  X,Y  65650,  18600  facing 
282°. 4 compass  degrees.  The  units  new  depth  will  be  50  meters  and  new 
width  will  be  300  meters.  At  any  time  other  than  during  initialization, 
the  only  part  of  this  event  notice  acted  upon  by  the  events  processor 
would  be  the  new  width  and  depth  for  the  unit.  No  unit  is  allowed  instant 
relocation  during  the  game. 


AD-A038  798 


UNCLASSIFIED 


TRW  DEFENSE  AND  SPACE  SYSTEMS  GROUP  REDONDO  BEACH  CALIF  F/G  15/7 
MATHEMATICAL  MODEL  USER'S  MANUAL  COMBINED  ARMS  TACTICAL  TRAININ— ETC (U) 
JAN  77  D S ADAMSON » E C ANDREANI*  G W ARCHER  N61339-73-C-0156 

NAVTRAEQUIPC-73-C-0156-E00  NL 


1 

2 


Event  Type  (=7) 

Subevent  Type  0 = red 
1 = blue 
3-28  Byte  Indicators 

0 = deactivate  unit 

1 = leave  alone 

one  byte  per  unit.  Defunct  units  and  dummy  units  are  skipped. 
64  Instructor  # 


f 
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SAMPLE  ACTIVATE  UNIT  EVENT 


ITMEVE  = 0, 

IVDT  = 7,  1,  257,  16777217,  16842752,  16843008,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  3, 


ACTIVATE  UNIT  EVENT  DESCRIPTION 

At  time  0,  9 blue  units  were  selected  to  be  activated.  The  4 
byte  packed  words  (3rd,  4th,  5th,  6th  words  of  event  notice)  in  Hex 
are:  00000101,  01000001,  01010000,  01010100.  Thus,  the  3rd,  4th, 

5th,  8th,  9th,  10th,  13th,  14th,  and  15th  units  in  the  LISTUN  array 
after  the  first  non-fake  blue  unit  in  the  LISTUN  array  have  been 
selected  as  the  active  blue  units.  Shown  below,  in  order,  are  the 
units,  their  #'s,  and  the  first  part  of  the  unit  list  as  input  to 
the  LISTUN  array  in  deck  to  CONTROL  LISTING  OF  UNITS  in  the  data  base: 

PARTIAL  UNIT  LIST  (STARTING  WITH  FIRST 
BLUE  UNIT) 


ACTIVATED  UNITS 
# NAME 


144 

142 

141 

139 

39 

47 

49 

50 

51 

53 

54 

56 
63 

57 
59 
80 
74 
82 


43 


49  l/A/2-77 

50  2/ A/2- 77 

51  3/ A/2-77 

56  l/B/2-77 

63  2/B/2-77 

57  3/B/2-77 

74  l/C/2-77 

82  2/C/2-77 

79  3/C/2-77 


Event  Type  (=8) 

1 : if  new  mission 

2:  if  modification 

3:  if  cancel 

1 : blue  recon 

2:  blue  strike 

3:  not  used 

4:  not'used 

5:  red  recon 

6:  red  strike 

Equipment  number  (aircraft  type) 

Number  of  aircraft  in  the  flight 

Name  of  mission 

Name  of  mission  (continued) 

Number  of  types  of  equipments  loaded 
Equipment  type  of  first  equipment 
Number  of  equipments  associated  with  word  9 
Equipment  type  of  second  equipment 
Number  of  equipments  associated  with  word  11 


Target  Type 

00  - Not  target 

1-100  - Unit  taraet  number 

201  - X-Y  Point  ' 

202  - Road 

203  - Bridge 

Route  point  associated  with  the  target 
Number  of  points  in  the  route 
X coordinate  of  route  point  1 

Y coordinate  of  route  point  1 

Altitude  of  route  point  1 (first  half  word) 
Velocity  of  route  point  1 (second  half  word) 

X coordinate  of  route  point  2 

Y coordinate  of  route  point  2 


Continue  for  each  route  point  up  to  a maximum  of  9. 
Instructor  # 
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SAMPLE  AIR  MISSION  EVENT 

ITMEVE  = 37, 

IVDT  =8,  1,6,  60,  2,  -641350560,  -1043736077,  1,  23, 

5,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

201,  3,  4,  30000,  30000,  1638850,  59000,  35000, 

1638850,  60500,  25000,  65536300,  30000,  30000, 

1638850,  0,  0,  0,  0,  0,  0,  0,  0,  0,:  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  2, 

★ 

AIR  MISSION  EVENT  DESCRIPTION 

At  37  minutes  into  the  game,  a new  air  mission,  a red  air  strike,  will 
begin  (the  planes  will  not  take  off  until  after  the  take-off  delay  time  set 
in  the  data  base  - usually  5 minutes,  but  the  mission  begins  when  the  count- 
down to  take-off  begins).  There  will  be  2 aircraft  type  60  (SU  - 7s).  The 
name  of  the  mission  will  be  displayed  as  RED-AIR3.  There  will  be  1 type  or 
ordnance  on  the  mission,  equipment  type  #23  (500  LB  SLICK  BOMB).  There  will 
be  5 of  these  loaded  on  each  of  the  2 planes.  The  target  is  an  X,Y  point. 
The  target  is  associated  with  point  #3  of  the  4 total  points  that  make  up 
the  route  the  planes  will  fly.  The  route  consists  of  the  following  X,Ys 
and  altitudes  and  velocities. 


POINT  # 

ALT  IN  METERS 

VELOCITY  IN  KNOTS 

X 

Y 

1 

25 

450 

30000 

30000 

2 

25 

450 

59000 

35000 

3 

1000 

300 

60500 

25000 

4 

25 

450 

30000 

30000 
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EVENT  TYPE  9 - Ground  Maneuver 


Word  I Contents 

Event  Type  (=9) 

Subevent  Type  (OP  - Type) 

=1  => HASTY  DEFENSE  (22) 

=2  => DELIBERATE  DEFENSE  (21 ) 

=3  => DELIBERATE  AMBUSH  (85) 

=4  =>DELAY  (31) 

=5  => WITHDRAW  (32) 

=6  => RECON  (17) 

=7  => RECON  FORCE  (12) 

=8  =>M0VE  TO  CONTACT  (11) 

=9  =>ATTACK  (13) 

=10  ^DISPLACING  (14) 

=11  => EXPLOIT/ PURSUIT  (16) 

Unit  Number  Under  Control 

Intent 

1 =>SEEK  ENGAGEMENT 

2 => ENGAGE  AS  NECESSARY 

3 => AVOID  ENGAGEMENT 

For  Subevent  Types  1,  2,  and  3 

SINE  of  direction  to  face 

For  Subevent  Types  1,  2,  and  3 

COSINE  of  direction  to  face 

Destination  Type 

= 1 => X-Y  COORD. 

=2  =>  UN  I T 

=3  => OLD  ROUTE  (Control  Measure) 

=4  =>SPECIAL  ROUTE 

X Coordinate  for  X-Y  COORD.  Destination 

Y Coordinate  for  X-Y  COORD.  Destination 
Unit  Number  for  UNIT  Destination 
Control  Measure  No.  for  OLD  ROUTE  Destination 
No.  of  Points  Defining  SPECIAL  ROUTE  (2-9) 

X Coordinate  of  Point  1 

Y Coordinate  of  Point  1 


X Coordinate  of  Point  9 
Y Coordinate  of  Point  9 
Mounted/Di smounted 
=1  =>Mounted 
=2  => Dismounted 
Instructor  # 


I ■ 
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sample  maneuver  event 


ITMEVE  = 15, 

IVDT  = 9,  10,  24,  3,  0,  0,  1,  55600,  21200,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

1,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  2, 


MANEUVER  EVENT  DESCRIPTION 

At  15  minutes  into  the  game,  unit  #24  will  go  into  operational  state 
14  (displacing)  and  move,  avoiding  engagement,  to  X,Y  destination 
55600,21200.  The  unit  will  move  mounted. 


1 

Page  5-954 

EVENT 

TYPE  10  - Ground  Fire 

Word 

Contents 

1 

Event  Type  (=10) 

2 

Subevent  Type 

0 = Percent  of  fire,  consider  suppression  as  a factor 

1 = Rounds  per  minute,  consider  suppression  as  a factor 

2 = Percent  of  fire,  ignore  suppression 

3 = Rounds  per  minute,  ignore  suppression 

7 = Cease  fire 

8 = Delete  entire  override  entry  for  fire  unit,  weapon  number 

3 

Firing  unit  number 

4 

Weapon  number  (equipment  number)  to  be  fired 

5 

Duration  of  fire  in  minutes 

6 

Number  of  targets  to  fire  at 

7 

First  target  number 

1-100  UNIT  # 

201  X.Y  POINT 

202  ROAD 

203  BRIDGE 

8 

Percent  (1-100)  or  rounds  per  minute  against  first  target 

9 

Target  X coordinate  (not  used  by  background  for  unit  targets  - 
current  unit  X,Y  is  used  when  event  occurs) 

10 

Target  Y coordinate 

11 

Second  target  number 

12 

Percent  (1-100)  or  rounds  per  minute  against  second  target 

13 

Second  target  X coordinate 

14 

Second  target  Y coordinate 

15-18 

Third  target 

19-22 

Fourth  target 

23-26 

Fifth  target 

27-30 

Sixth  target 

31-34 

Seventh  target 

35 

Eighth  target  number 

36 

Percent  (1-100)  or  rounds  per  minute  against  eighth  target 

37 

Target  X coordinate  (not  used  by  background  for  units  targets  - 
current  unit  X,Y  is  used  when  event  occurs) 

38 

Target  Y coordinate 

64 

Instructor  # 

L. 

j 

Page  5-955 


SAMPLE  FIRE  EVENT 

ITMEVE  = 48, 

I VDT  = 10,  1,  25,  17,  2,  1,  201,  6,  68000,  19000, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  2, 

★ 

FIRE  EVENT  DESCRIPTION 

At  48  minutes  into  the  game,  unit  #2  will  fire  6 rounds/minute  from 
equipment  #17  (152MM  GUN/HOWITZER)  for  2 minutes  at  1 target.  This  tar- 
get is  X,Y  point  68000,  19000. 


- — - - 


2 

3 


4 - 63 
64 


Event  Type  (=14) 

Mot  used 

Air  Defense  Flag 

=1  = FIRE  AT  WILL 

=2  = FIRE  IF  ATTACKED 
=3  = DON'T  FIRE 

Unit  numbers  to  which  command  applies 
Instructor  # 
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SAMPLE  AIR  DEFENSE  EVENT 


ITMEVE  = 0, 

IVDT  = 14,  0,  1,  71,  72,  73,  74,  75,  76,  77,  78, 
81,  82,  83,  84,  85,  86,  87,  88,  89,  90,  91 
95,  96,  97,  98,  99,  0,  0,  0,  0,  0,  0,  0,  0 
0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 
0,  0,  0,  1, 


AIR  DEFENSE  EVENT  DESCRIPTION 

At  time  0,  and  from  then  on  until  another  air 
their  orders,  the  following  units  will  fire  at  will 
within  range:  unit  numbers  71,  72,  73,  74,  75,  76 
82,  83,  84,  85,  86,  87,  88,  89,  90,  91,  92,  93,  94 


79,  80, 

, 92,  93,  94, 

> 

o,  0,  0,  0,  0,  0, 


defense  event  changes 
at  any  enemy  aircraft 
, 77,  78,  79,  80,  81, 

, 95,  96,  97,  98,  and 


SAMPLE  PREPLANNED  MISSION  EVENT 


ITMEVE  =12, 

IVDT  = 15,  0,  2,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  1, 

• k 

PREPLANNED  MISSION  EVENT  DESCRIPTION 

At  12  minutes  into  the  game,  preplanned  mission  f>2  will  be  read  from 
the  preplanned  mission  file  and  executed. 


r 
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Event  Type  (=16) 

Subevent  Type 

=1  = CREATE  A NEW  TEAM 
=2  = ADD  A UNIT  TO  A TEAM  (NO  MENU  PAGE 
EXISTS  TO  SELECT  THIS  OPTION) 

=3  = DELETE  UNITS  IN  A TEAM 
=4  = REDEPLOY  UNITS  IN  A TEAM  (NO  MENU 
PAGE  EXISTS  TO  SELECT  THIS  OPTION) 

Size  of  team:  (For  CREATE  only) 

Operational  Group  Number 

No.  of  units  in  list 

Next  higher  command  unit  number  (For  CREATE  only) 
X location  for  deployment 
Y location  for  deployment 


r LETE 

— 

CREATE 

9 

Fi rst  uni t deleted 

SINE  of  direction  of  movement 

10 

His  next  higher  command 

COSINE  of  direction  of  movement 

11 

Second  unit  deleted 

Intent: 

=1  = Avoid  Engagement 

=2  = Engage  as  necessary 

=3  = Seek  Engagement 

12 

His  next  higher  command 

1st  uni t affected 

13 

II 

forward  distance  (-means  rearward  of  center) 

14 

II 

lateral  distance  (-means  to  the  right) 

15 

II 

2nd  unit  affected 

16 

If 

forward  distance 

17 

II 

lateral  distance 

18 

II 

3rd  unit  affected 

19 

ll 

forward  distance 

20 

II 

lateral  distance 

64 

Instructor  ft 

. A 

SAMPLE  TASKING  ORGANIZATION  EVENT 


ITMEVE  = 0, 

IVDT  = 16,  1,  1,  6,  6,  136,  72540,  21721,  0, 

-1091567616,  2,  54,  -250,  -50,  56,  0,  -550, 

55,  -900,  -400,  63,  -100,  500,  62,  -50,  -150 
59,  -550,  -400,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 

0,  0,  0,  1, 

★ 

TASKING  ORGANIZATION  EVENT  DESCRIPTION 

At  time  0,  a new  op  group  will  be  created.  It  will  be  a company 
sized  op  group,  and  it  will  use  the  name  input  in  the  data  base  for  op 
group  #6.  There  are  6 units  to  be  combined  into  this  new  group.  The 
next  higher  command  of  the  op  group  will  be  "fake  unit"  #136.  The  op 
group  will  deploy  with  its  center  at  X,Y  72540,  21721.  Figure  5-145. 
on  the  next  page  will  illustrate  this.  The  direction  of  movement,  or 
facing  direction,  will  be  270°  (sin  = 0,  cos  = -1).  The  units  in  the 
op  group  get  travel  code  (intent)  2.  Unit  54  will  be  250  meters  to 
the  rear  and  50  to  the  right  of  center,  56  will  be  0 meters  behind  and 
550  meters  to  the  right,  55  will  be  900  meters  to  the  rear  and  400 
meters  to  the  right,  63  will  be  100  meters  to  the  rear  and  500  meters 
to  the  left  of  center,  62  will  be  50  meters  to  the  rear  and  150 
meters  to  the  right  and  59  will  be  550  meters  to  the  rear  and  400 
meters  to  the  right.  Tasking  organization  events  executed  concur- 
rently with  the  first  2 halts  during  initialization  will  result  in 
instant  deployment  of  the  op  group  to  the  selected  locations.  After 
this  (the  "LAST  CHANCE  TO  RELOCATE  UNITS"  message  is  output  at  the 
2nd  halt),  the  units  will  move  at  a normal  rate  of  speed  in  the 
normal  manner  to  deploy  to  these  locations. 


Page  5-963 


5.9. 1.2  Assumptions  and  Data  Sources 
(none) 

5.9. 1 . 3 Equations 
(none) 

5.9.2  Table  Driven  Command  and  Control  Submodule 
5.9.2. 1 Operation 

The  Table  Driven  Command  and  Control  Submodule  was  adopted  virtually 
intact  from  the  old  MAFIA  V simulator  which  was  adapted  as  the  basis  for 
CATTS.  The  modifications  made  primarily  involve  increasing  maximum  table 
sizes.  There  are  also  modifications  to  prevent  table-driven  maneuver 
decisions  for  any  unit  currently  under  event-driven  maneuver  control 
(described  in  Section  5.9.1).  Since  the  submodule  described  in  this 
section  (5.9.2)  has  been  little  changed,  the  interested  reader  is  strongly 
recommended  to  consult  the  MAFIA  V User's  Manual , which  contains  detailed 
descriptions  of  the  data  tables  and  decision  criteria  used.  The  MAFIA  V 
Programming  Report  can  also  be  a valuable  source  of  information,  as  it 
shows  detailed  loyic  flows  for  each  subroutine.  CATTS  Data  Requests 
13  and  17  also  contain  seventy-eight  pages  of  explanations  of  value  to 
someone  trying  to  understand  the  CATTS  Table  Driven  Command  and  Control 
Submodule.  Finally,  Section  5.9.17  of  the  CATTS  Trainer  Programming 
Report  contains  twenty  pages  of  description  of  this  submodule. 

Subroutine  linkages  for  the  Table  Driven  Command  and  Control  Submodule 
are  shown  in  Figure  5-146.  Table  5-62  gives  a brief  description  of  each 
subroutine,  along  with  its  principal  inputs  and  outputs. 

There  are  3 data  base  tables  that  control  the  table  driven  command  and 
control  submodule.  These  are  the  Change  of  State  Table  (I0PTB1,  I0PTB2),  the 
Movement  Code  Change  Table  (MVCHG1 , MVCHG2),  and  the  Op  State  Updating 
Table  (MVCHG3).  These  3 tables  were  the  old  MAFIA  V command  and  control 
method.  This  command  and  control  includes  control  over  maneuvering  and 
firing  and  some  effect  on  tasking  organization.  The  table  command  and 
control  provides  control  by  changing  the  following  items:  operational 

state  (IOPSTU(I)),  movement  code  (MVTCD(I)  & MTCD0G( I0G)),  travel  code 
(ITRAV(I),  ITRAVG( IOG) ) , deployment  code  ( I DPCOD ( I OG ) ) , and  leaving  or 


Figure  5-146.  Table-Driven  Command  and  Control  Subroutine  Linkage 
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Subroutine  Description  Principal  Inputs/Outputs 
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NCRIT  - Change  of  state  criterion 

number  specified  by  table 
I0PTB2(NTEST). 


Table  5-62.  Table-Driven  Command  and  Control  Submodule  Subroutine  Description  (Continued) 


Page  5-967 


J 


(That  is,  K represents 
the  other  force  not 
represented  by  J). 


Table  5-62.  Table-Driven  Command  and  Control  Submodule  Subroutine  Description  (Continued) 


Include  support  fire. 


Table  5-62.  Table-Driven  Command  and  Control  Submodule  Subroutine  Description  (Continued) 


Subroutine  Description  Principal  Inputs/ Outputs 

NEWMOV  Input:  MVCHGl(I.J) 

(Cont'd)  (Cont'd) 
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fable  5-62.  Table-Driven  Command  and  Control  Submodule  Subroutine  Description  (Continued) 
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not  leaving  an  op  group  (INOG(I)).  The  table  driven  command  and  control 
can  compliment  the  menu/events  command  and  control  discussed  in  the  pre- 
vious section,  but  it  may  also  interfere  with  the  menu/events  command  and 
control.  Thus,  the  user  must  take  care  when  adding  new  entries  to  any  of 
the  3 command  and  control  tables.  Obviously,  new  entries  should  be  tested 
before  being  used  in  a game  and  removed  if  they  do  interfere  in  an  undesir- 
able way  with  the  meriu/events  command  and  control.  There  are  2 cases  where 
no  interference  can  occur:  1)  any  unit  under  event  maneuver  command  and 

control  cannot  be  affected  by  the  table  driven  command  and  control,  and  2) 
any  unit  delayed  by  an  obstacle  cannot  be  affected  by  the  table  driven 
command  and  control.  This  means  that  units  under  menu/event  fire  control 
can  be  interfered  with  via  table  driven  command  and  control,  and  that 
tasking  organization  can  be  affected  by  the  table  driven  command  and  con- 
trol anytime. 

There  are  two  parts  to  each  of  these  3 tables:  a selection  portion 

and  an  action  portion.  The  selection  portion  is  examined  to  determine  if 
a change  should  occur,  and  if  a change  is  to  occur,  the  numbers  in  the 
action  portion  are  put  in  the  appropriate  array  to  ma*.e  the  change  occur. 

The  Change  of  State  Table  is  the  main  action  table,  the  driving  command 
and  control  table.  The  other  2 are  reaction  tables  that  react  to  changes 
that  occur.  The  Change  of  State  Table  is  searched  automatical ly  for  every 
unit  every  time  step  and  only  units  under  maneuver  event  control  (MOVECC(IU)  * 0) 
and  units  delayed  by  an  obstacle  ( I0BSTATU( IU)  = 2)  are  not  compared  to  the 
selection  word  of  this  table.  The  Movement  Code  Change  Table  is  searched 
only  when  a unit  arrives  at  a destination  or  a unit  has  had  its  op  state 
changed  by  the  Change  of  State  Table.  The  Cp  State  Updating  Table  is  only 
searched  after  a unit's  movement  code  has  been  changed  by  a value  set  in  the 
program  code  (many  of  these  automatic  movement  code  changes  are  in  the 

engagement  logic)  or  after  a unit  has  it's  movement  code  changed  to  match 
that  of  its  operational  group. 

There  is  also  a data  array  associated  with  the  Change  of  State  Table 
and  another  associated  with  the  Movement  Code  Change  Table.  The  Decision 
Value  array  (DECVAL)  contains  values  used  with  the  selection  portion  of  the 
Change  of  State  Table.  The  Movement  Data  array  (MVDATA)  contains  values  to 
be  used  with  the  action  portion  of  the  Movement  Code  Change  Table. 


Page  5-977 


Descriptions  of  the  specific  operations  of  each  of  the  3 command  and 
control  tables  follow. 

Change  of  State  Table 

The  purpose  of  this  table  is  to  serve  as  the  prime  command  and  control 
table.  It  changes  directly  only  Operational  State  ( I OPSTU ( I U ) ) , and  the 
leaving  of  an  op  group  by  a unit  ( I NOG ( I U ) ) . However,  a change  of  state  by 
this  table  causes  the  Movement  Code  Change  Table  to  be  searched,  and  this 
can  change  movement  code  (MVTCD(IU)),  travel  code  of  a unit  (ITRAV(IU)),  de- 
ployment code  of  an  op  group  ( I DPCOD  ( IOG) ) , op  state  ( I OPSTU  ( III) ) , and  move- 
ment data  (MVDTl(IU)  , MVDT2(IU),  and  MVDT3(IU)).  Every  time  step,  the 
first  2 words  ( I OPTB 1(1,1),  I0PTB1 (1,2)  for  each  entry  number  I in  the  Change 
of  State  Table  are  searched  to  see  if  the  values  match  the  current  values  for 
each  unit  IU  that  is  active  ( I STATU ( I U ) * 1),  and  not  under  menu/event  maneu- 
ver control  (MOVECC(IU)  = 0)  and  not  delayed  as  a result  of  an  obstacle  encoun- 
ter (IOBSTATU(IU)  * 2).  Each  of  the  entry  words  ( I0PTB1 (1,1),  10PTB(1,2) 
contain  an  11  digit  number  of  the  form  UUVVWXXYYZZ  where 

UU  = unit  type  (01-20)  (00  =>  any  type) 

VV  = op  group  number  of  the  unit  (01-20)  (00  =>  disregard  this  factor, 

99  =>  any  unit  not  in  an  op  group) 

W = color  (1  = red,  2 = blue,  0 = either) 

XX  = unit's  movement  code  (01 -16),  (00  =>  any  code,  88  =>  any  engaged 
code  (1-4),  99  =>  any  non-engaged  code  (5-16)) 

YY  = unit's  current  op  state  (01-98)  (00  =>  any  state)  also,  any 
op  state  entry  evenly  divisible  by  10  (i.e.,  10,  20,  30,  etc.) 
will  match  any  unit  op  state  with  the  same  digit  in  the  tens 
place.  Thus,  YY  = 20  would  match  op  states  20,  21,  22,  23, 

24,  25,  26,  27,  28,  and  29.  Thus,  when  putting  op  states  in 
the  mode  table,  op  states  which  are  divisible  evenly  by  10 
should  be  avoided,  because  they  can't  be  singled  out  by  this 
command  and  control  table. 

ZZ  = unit  number  (01-99)  (00  = any  unit  number) 

If  the  current  values  of  a unit  match  all  of  the  data  specified  in  the 
first  2 words  of  entry  I,  the  first  part  of  the  tfiird  word  of  entry  I ( I 0PTB2 ( I ) ) 
is  consulted  to  see  if  the  change  contained  in  the  second  part  will  be  made. 
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If  no  match  for  a unit  is  found,  the  table  search  continues  with  the 
next  unit.  This  third  associated  word  I 0PTB2 ( I ) has  the  form  AABBBCCL)  where 

AA  = number  of  the  change-of-state  criteria  to  use  (1  through  85 
tests  performed  by  the  software  subroutine  CHGCRIT). 

BBB  = entry  number  of  the  decision  value  in  the  DttVAL  data  array 
to  be  used  with  the  criterion.  If  two  values  are  required 
with  a criterion,  they  must  be  listed  consecutively  in  the 
DECVAL  array.  In  this  case,  the  AA  above  points  to  the 
first  value,  and  the  program  automatically  uses  the  next 
entry  for  the  second  value. 

j*  CC  = new  op  state  of  unit  if  criterion  is  satisfied. 

D = leave  or  don't  leave  current  op  group  (0=>  don't  leave,  >0  => 
leave) . 

The  criterion  number  specified  in  the  AA  portion  of  the  word  is  evaluated 
using  the  value(s)  specified  in  DECVAL  (BBB),  where  BBB  is  a 3-digit  pointer 
into  the  DECVAL  array  (if  more  than  one  value  is  required,  BBB  points  to  the 
first).  If  the  test  is  passed,  the  operational  state  of  the  unit  is  set 
equal  to  the  value  specified  in  item  CC  of  the  I0PTB2  word.  Finally,  code  D 
indicates  whether  or  not  the  unit  should  leave  its  operational  grouping. 

If  the  test  is  not  passed,  the  table  search  for  the  unit  continues. 

After  a unit  undergoes  a change  in  its  operational  state,  a second  pass 
is  made  through  the  I0PTB1  array  to  determine  if  a second  change  is  required 
(the  new  op  state  is  used  in  the  second  search).  No  more  than  two  opera- 
tional state  changes  will  be  made  to  a unit  in  a given  time  step.  If  a change 
of  state  occurs,  the  Movement  Code  Change  Table  is  searched  to  determine 
whether  the  movement-  code  should  also  be  changed.  Even  though  the  Movement 
Code  Change  Table  can  change  op  state,  when  searched  as  a result  of  an  op 
state  change,  the  Movement  Code  Change  Table  is  not  allowed  to  make  op  state 
changes . 

If  the  value  of  I0PTB2,  representing  criteria  number,  etc.,  is  negative, 
it  is  set  to  positive  before  extracting  the  packed  data.  After  processing 
the  data,  the  corresponding  entry  in  I 0PTB1 ( i , 1 ) is  set  to  999999999,  effec- 
tively eliminating  that  entry  from  the  table  for  the  remainder  of  the  exer- 
cise. 


mi  « ‘•  ■■auaaw",' 
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There  are  85  different  criteria  evaluated  in  subroutine  CHGCRT. 

These  criteria  are  hard-coded  in  the  subroutine.  A list  of  the  85  criteria 
can  be  found  iri  Table  5-63,  where  the  unit  being  processed  is  referred  to 
as  "unit  I,"  and  the  threshold  value  is  "IDATA"  (second  threshold  value, 
if  applicable,  is  "IDATA1"). 

Movement  Code  Change  Table 

The  purpose  of  this  table  is  to  react  to  2 circumstances: 

• units  arriving  at  destination 

• units  changing  op  states  as  a result  of  Change  of  State  Table 
(COS)  entries 

It  directly  changes  movement  code  (MVTCD(  III) ) , travel  code  ( ITRAV(IU) ) , 
deployment  code  ( IDPC0D( IOG) ) , op  state  ( I OPSTU ( I U ) ) , and  movement  data 
(MVDTl(IU),  MVDT(IU),  MVDT3(IU)).  When  a unit  arrives  or  gets  a COS  op 
state  change,  the  first  2 words  (MVCHG1 ( I , J) , J = 1 , 2)  of  the  Movement 
Code  Change  Table  are  compared  to  the  units'  current  values.  If  all  of 
the  values  match,  the  appropriate  unit  variables  are  set  equal  to  the 
values  in  the  associated  third  word  (MVCHG2(I))  of  entry  I,  and  the  move- 
ment data  variables  are  set  equal  to  the  values  from  the  movement  data 
array  (MVDATA(J))  (pointed  to  by  MVCHG2). 

The  first  2 words  (MVCHG1 ( I , J) , J = 1 , 2)  of  each  entry  have  the  form 
UUVVWXXYYZZ  where 

UU  = unit  type  (01-20)  (00  =>  any  type) 

VV  = op  state  of  unit  (01-98)  (00  =>  any  state),  also  any  op  state 
entry  evenly  divisible  by  10  (i.e.,  10,  20,  30,  etc.)  will 
match  any  unit  op  state  with  the  same  digit  in  the  ten's 
place.  Thus,  VV  = 20  would  match  current  unit  op  states  20, 

21,  22,  23,  24,  25,  26,  27,  28,  and  29.  Thus,  when  putting  op 
states  in  the  mode  table,  op  states  which  are  evenly  divisible 
by  10  should  be  avoided,  because  they  can’t  be  singled  out  by 
this  command  and  control  table. 

W = color  (1  = red,  2 = blue,  0 = either) 

XX  = movement  code  of  unit  (01-16)  (00  =>  any  code) 

YY  = op  group  number  (01-20)  (00  =>  disregard  this  factor,  99  = any 
unit  not  in  an  op  group) 


1 


ZZ  = unit  number  (01-99)  (00  =>  any  unit) 


Page  5-980 


0) 

(2) 

(3) 

(4) 

(5) 

(6) * 

(7) * 

(8) 

(9) 

(10)* 

(ID* 

(12)* 

(13) * 

(14) * 

(15) * 

(16) * 

(17) * 

(18) * 

(19) * 

(20) 
(21) 
(22) 

(23) 

(24) 

(25) 


(26) 


(27) 


Table  5-63.  Change  of  State  Criteria 

time  — I DATA 
time  = IDATA 

x coordinate  of  unit  I > IDATA 

x coordinate  of  unit  I ^ IDATA 

x coordinate  of  unit  I (rounded  to  nearest  100)  = IDATA 

Distance  from  unit  I to  nearest  enemy  unit  in  same  engagement  IDATA 

Distance  from  unit  I to  nearest  enemy  unit  in  same  engagement  > IDATA 

Distance  from  unit  I to  nearest  enemy  unit  — IDATA 

Distance  from  unit  I to  nearest  enemy  unit  > IDATA 

Distance  between  unit  I and  enemy  FEBA  — IDATA 

Distance  between  unit  I and  enemy  FEBA  > IDATA 

Distance  between  unit  I and  friendly  FEBA  IDATA 

Distance  between  unit  I and  friendly  FEBA  > IDATA 

x coordinate  of  the  location  of  the  enemy  FEBA  £=  IDATA 

x coordinate  of  the  location  of  the  enemy  FEBA  > IDATA 

x coordinate  of  the  location  cf  the  friendly  FEBA  IDATA 

x coordinate  cf  the  location  of  the  friendly  FEBA  ]>  IDATA 

Distance  between  the  opposing  FEBAs  — IDATA 

Distance  between  tne  opposing  FEBAs  > IDATA 

Degree  of  suppression  of  unit  I — IDATA 

Degree  of  suppression  of  unit  I < IDATA 

Not  used 

Unit  I is  below  critical  minimum  level  for  at  least  one  principal 
ammunition  type 

Unit  I is  above  critical  minimum  level  for  it  least  one  principal 
ammunition  type 

Unit  I is  below  critical  minimum  level  for  all  principal  ammunition 
types 

Unit  I is  above  critical  minimum  level  for  all  princ 
ammunition  types 

1 _ ml ( 2.  IDATA  (fraction  of  men  lost  in  unit  I 

mj(0) 
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Table  5-63.  Change  of  State  Criteria  (Cont'd) 


(28) 


! . nji(t)  _> 

nj i (0) 


IDATA  (fraction  of  first  equipment  type  in  *** 
unit  I that  is  lost) 


(29)*  1 - 


anj(t) 

lmj(0) 


IDATA  (for  friendly  units  J in  the  same  *** 
engagement  as  unit  I with  a status 
code  equal  to  1 ) 


(30) 

1 

5JT5T  x 

6m  ^ 
fit 

>_  IDATA  *** 

(31) 

1 

HijToy  * 

fimj 

at 

4 IDATA  *** 

(32) 

i 

nIl  (0) 

“n 

fit 

^ IDATA  *** 

(33) 

X 

o 

c 

fin. 

M 

fit 

< IDATA  *** 

(34)* 

1 

rfimj 

^ IDATA  (for  friendly  units  J 

in  the  same  *** 

inij(0) 

St 

engagement  as  unit  I 
code  equal  to  1 ) 

with  a status 

(35)* 

mj(0)  - 

mj(t) 

distance  to  enemy  FEBA 

5mI  > IDATA 

mI 

To]- 

uni  ‘ I movement  rate  * m, 

j(0)6t 

(36) *  The  Force  Ratio**— IDATA  (for  all  friendly  units  0 and  enemy  units  K 

in  the  same  engagement  as  unit  I witn  a status  coae  of  1) 

(37) *  The  same  as  36  except  that  all  units  J and  K must  be  on  the  same  side 

of  the  Engagement  Axis  as  unit  I 

(38) *  The  Force  Ratio**  IDATA  (for  all  friendly  units  J and  enemy  units  K 

in  the  same  engagement  as  unit  I with  a status  code  of  1) 


(39)*  The  same  as  38  except  that  all  units  J and  K must  be  on  the  same  side 
of  the  Engagement  Axis  as  unit  I 
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Table  5-63.  Change  of  State  Criteria  (Cont'd) 

(40) *  Position  of  unit  IDATA  ^ I DATA!  from  its  enemy  FEBA 

(41) *  Position  of  operational  grouping  IDATA  — IDATA1  from  its  enemy  FEBA 

(42) *  Position  of  unit  IDATA  > IDATA1  from  its  enemy  FEBA 

(43) *  Position  of  operational  grouping  IDATA  IDATA1  from  its  enemy  FEBA 

(44)  Unit  IDATA  is  in  state  IDATA1 

(45)  The  forward-most  unit  of  operational  grouping  IDATA  is  in  state  IDATA1 

(46) *  For  the  engagement  of  unit  IDATA,  the  distance  between  the  Red  and 

Blue  FEBAs  ^ IDATA1 

(47) *  For  the  engaaement  of  unit  IDATA,  the  distance  between  the  Red  and 

Blue  FEBAs  > IDATA1 

(48) *  For  the  engagement  of  operational  grouping  IDATA,  the  distance 

between  the  Red  and  Blue  FEBAs  IDATA! 

(49) *  For  the  engagement  of  operational  grouping  IDATA,  the  distance 

between  the  Red  and  Blue  FEBAs  > IDATA! 

(50)  Unit  IDATA  is  engaged 

(51)  Operational  grouping  IDATA  is  engaged 

(52)  Unit  IDATA  is  not  engaged 

(53)  Operational  grouping  IDATA  is  not  engaged 

(54) *  For  the  engagement  of  unit  IDATA,  the  Force  Ratio**  in  the  Close 

Support  Region  < IDATA1 

(55) *  For  the  engagement  of  unit  IDATA,  the  Force  Ratio**  in  the  Close 

Support  Region  > IDATA1 

(56) *  For  the  engagement  of  unit  IDATA,  the  Force  Ratio**  in  the  Close 

Support  and  Interdiction  Regions  < IDATA1 

(57) *  For  the  engagement  of  unit  IDATA,  the  Force  Ratio**  in  the  Close 

Support  and  interdiction  Regions  I DATA! 

(58) *  Same  as  54  except  use  operational  grousing  IDATA 

(59) *  Same  as  55  except  use  operational  grouping  IDATA 


J 


1 
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Table  5-63.  Change  of  State  Criteria  (Cont'd) 

(60)* 

Same  as  56  except  use  operational  grouping  IDATA 

(61)* 

Same  as  57  except  use  operational  grouping  IDATA 

(62)* 

For  the  engagement  of  unit  IDATA,  the  Force  Ratio**  in  the 
half-sector  of  the  Close  Support  Region  <C  IDATA! 

left 

(63)* 

For  the  engagement  of  unit  IDATA,  the  Force  Ratio**  in  the 
half-sector  of  the  Close  Support  Region  -2d  IDATA1 

left 

(64)* 

For  the  engagement  of  unit  IDATA,  the  Force  Ratio**  in  the 
half-sector  of  the  Close  Support  Region  < IDATA1 

right 

(65)* 

For  the  engagement  of  unit  IDATA,  the  Force  Ratio**  in  the 
half-sector  of  the  Close  Support  Region  IDATA1 

right 

(66)* 

Same  as  62  except  operational  grouping  IDATA 

(67)* 

Same  as  63  except  operational  grouping  IDATA 

(68)* 

Same  as  64  except  operational  grouping  IDATA 

(69)* 

Same  as  65  except  operational  grouping  IDATA 

(70) 

Destination  unit  or  operational  grouping  is  defunct 

(71) 

Destination  engagement  is  defunct 

(72) 

Rounds  of  support  weapon  fire/unit  area  falling  on  unit  I - 

^ IDATA 

(73) 

Rounds  o^  support  weapon  fire/unit  area  falling  on  unit  I IDATA 

(74) 

Status  code  of  unit  IDATA  = 1 

(75) 

Status  code  of  unit  IDATA  f 1 

(76) 

/ 

x-coordinate  of  unit  IDATA  — IDATA! 

(77) 

x-coordinate  of  unit  IDATA  > I DATA! 

(78) 

x-coordinate  of  operational  grouping  IDATA  IDATA1 

(79) 

x-coordinate  of  operational  grouping  IDATA  IDATA1 

(80) 

This  criterion  sets  the  delay  counter  to  IDATA  unless  the 
delay  counter  is  not  zero;  normally,  no  cnange-of-state 
should  be  indicated 

(81) 

This  criterion  decrements  the  delay  counter  of  the  unit  by  the 
magnitude  of  the  time  increment.  A change-of-state  w’ll  occur 
when  tr  delay  counter  is  less  than  or  equal  to  the  time  increment 
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Table  5-63.  Change  of  State  Criteria  (Cont'd) 

(82)  Differe^je  Detween  x-coordinates  of  units  I and  IDATA  — ipATAl 

(83)  Difference  between  x-coordinates  of  units  I and 
IDATA  > I DATA! . 

(84)  (Distance  between  units  I and  IDATA)  <_  IDATA! . 

(85)  (Distance  between  units  I and  IDATA)  > IDATA1. 

♦Unit  I must  be  engaged  or  the  test  automatically  fails. 

^U6nJ6  + Measure  of  friendly  support  fire 
♦♦The  Force  Ratio  is  

^ubnKb  + Measure  of  enemy  support  fire 

where  6 ranges  over  all  equipment  types  in  the  friendly  unit  J. 

b ranges  over  all  equipment  types  in  the  enemy  unit  K. 
u is  the  equipment  wei ght  'or  equipment  number  n 

♦♦♦Variables  used  in  defining  criteria  27  through  35  are  defined  as  follows: 


rrij(O)  = number  of  personnel  in  unit  I at  time  0. 
mj(t)  = number  of  personnel  in  unit  I at  time  t. 

5m. 

s number  of  men  lost  in  last  time  step. 

n.  (0)  = number  of  pieces  of  first  eauipment  on  unit  I ' s 

A1  equipment  list  at  time  0. 

rtj  (t)  = number  of  pieces  of  first  equipment  on  unit  I ' s 

X1  equipment  list  at  time  t. 


number  of  pieces  of  first  eauipment  on  unit  I ’ s 
equipment  list  in  last  tine  step. 


6t 
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The  action  word  - the  third  word  (MVCHG2(I))  - has  the  form  EEFGJJKKK, 

where 

EE  = new  movement  code  of  unit 
F = new  travel  code  of  unit  (0  =>  no  change) 

G = new  deployment  code  (only  a value  of  1 has  any  effect) 

JJ  = new  op  state  of  unit  (00  =>  no  change.  00  must  be  used  with 
entries  that  are  to  be  activated  due  to  COS  op  state  change) 

KKK  = entry  number  of  movement  data  (MVDATA)  of  the  first  movement 

data  associated  with  the  new  movement  code.  Up  to  three  values 
can  be  needed,  and  these  must  be  consecutive  in  the  MVDATA  array. 

See  table  of  movement  codes  for  which  of  the  3 values  are  required. 

If  no  match  occurs  with  the  MVCHG1  words,  the  unit  will  keep  it's  cur- 
rect  movement  values. 

Note  that  finding  a match  among  the  entries  of  array  MVCHG1  does  not  guarantee 
a movement  change.  A very  important  restriction  is  the  following:  units  may 

not  be  changed  from  an  unengaged  (5-16)  to  an  engaged  (1-4)  movement  code. 

Such  a change  is  performed  automatically  by  built-in  software  during  arrival 
and  engagement  processing.  The  same  is  true  when  a unit's  movement  code  is 
being  changed  to  4 or  16  (deployed  and  waiting).  Built-in  software  will 
nandle  this,  and  any  attempt  to  produce  such  a change  (via  arrays  MVCHG1  and 
MVCHG2)  is  ignored.  Also,  if  the  movement  code  change  is  the  result  of  an 
op  state  change  from  the  Change  of  State  Table,  is  a new  state  (JJ  = 00)  is 
specified,  the  whole  action  word  (MVCHG2)  will  be  ignored.  Also,  if  an 
arriving  unit  belongs  to  an  op  group,  and  another  unit  in  the  op  group  has 
already  arrived  and  gotten  the  movement  code  for  itself  and  the  op  group, 
the  table  will  not  be  searched  for  the  unit. 

Op  State  Updating  Tabl e 

The  purpose  of  this  table  is  to  change  a unit's  op  state  after  it's  move- 
ment code  has  been  changed  by  some  means  other  than  the  Movement  Code  Change 
Table  or  the  menu  events.  Basically,  this  allows  an  appropriate  op  state 
change  for  a unit  that  gets  a hard  coded  movement  code.  This  table  changes 
only  the  op  state  ( I OPSTU ( I U ) ) of  a unit. 

A unit  can  have  its  movement  code  changed  automatically  by  the  engage- 
ment logic.  Also,  a unit  can  have  its  movement  code  changed  to  match  that 
of  the  op  group  to  which  it  belongs.  After  all  such  instances  of  movement 


J 
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code  change,  the  current  values  of  a unit  are  matched  against  the  2 words  of 
the  I entries  in  the  Op  State  Updating  Table  ( MVCHG3 ( I ,J) , J = 1,  2).  These 
words  have  the  form  TTUUVWWXXZZ,  where 

TT  = unit  number  (01-99)  (00  =>  any  number) 

UU  = unit  type  (01-20)  (00  =>  any  type) 

V = color  (1  = red,  2 = blue,  0 = either) 

WW  = op  group  number  of  the  group  the  unit  belongs  to  (01-20)  (00  => 
disregard  this  factor,  99  =>  any  unit  not  in  an  op  group) 

XX  = movement  code  of  unit  - recently  changed  (01-16)  (00  =>  any  code) 

ZZ  = new  op  state  of  unit 

If  the  unit  matches  all  the  values  of  one  of  the  entries  in  this  table, 
the  units  op  state  ( I 0PSTU ( I U ) ) will  be  set  equal  to  the  value  specified  in  the 

11  portion  of  the  matching  entry.  Thus,  units  that  receive  hard  coded  move- 
ment code  changes  can  be  made  to  change  to  appropriate  op  states. 

5. 9. 2. 2 Assumptions  and  Data  Sources 

There  are  some  hard  coded  command  and  control  decision  rules  relevant 
to  this  submodule.  These  involve  changing  a unit's  movement  code  (MVTCD(IU) 
and  movement  data  (MVDTl(IU),  MVDT2(IU),  and  MVDT3(IU))  by  subroutines 
NEWM0V  and  ARRIVE.  All  of  these  hard  coded  rules  are  detailed  in  the  flow 
diagrams  of  these  2 subroutines  in  Section  5.5.2. 

These  assumptions  were  made  by  the  original  MAFIA  programmers. 


5. 9. 2. 3 Equations 
(None) 
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5.10  MISCELLANEOUS  AND  ANCILLARY  MODULE 

The  subroutine  and  function  subprograms  described  in  this  section  per- 
form support  calculations  generally  used  in  more  complex  computations  in 
other  modules.  These  are  primarily  interpolations,  geometric  calculations, 
and  utility  functions.  Most  of  the  routines  are  written  in  FORTRAN  and 
taken,  in  most  cases,  from  the  MAFIA  V Program.  Xerox  assemoly  language 
nas  been  used  in  cases  where  it  proved  to  increase  computational  efficiency. 

With  the  exception  of  the  two  subroutines  described  in  Sections  5.10.30 
and  5.10.34,  REDIST  and  USEFUEL,  respectively,  all  other  subroutines  des- 
cribed herein  are  designed  to  solve  fairly  simple  geometric  problems  or  to 
do  table  look-up  operations. 

5.10.1  Subroutine  CHKL0S(IX1,  1X2,  IX, K) 

5.10.1  .1  Operation 

This  subroutine  determines  whether  or  not  IX  has  a value  between  T X 1 
and  1X2.  If  IX  is  less  than  1X2  and  greater  than  1X1,  or  less  than  1X1  and 
greater  than  1X2,  K.  is  set  to  2.  Otherwise,  i<  is  set  to  1.  I XI  , 1X2,  and 
IX  are  inputs  to  this  subroutine.  K is  output  by  this  subroutine. 

5.10.1.2  Assumptions  and  Data  Sources 
(None) 

5.10.1 .3  Equations 

1X1  < IX  < 1X2 
1X2  < IX  < 1X1 

5.10.2  Subroutine  CKL0SC( 1X1,  IY1 , 1X2,  IY 2 , IRC,  1X3,  IY3,  K) 

5.10.2.1  Operation 

This  subroutine  is  used  to  determine  whether  the  line  segment  defined  by 
( I XI , I Y 1 ) (1X2,  IY2)  intersects  a circle  of  radius  IRC  centered  at  (1X3,  IY3) 
If  an  intersection  exists,  K is  set  to  2.  If  no  intersection  exists,  K is 
set  to  1 . 
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1X1 , IY1,  1X2,  IY2,  1X3,  IY3,  IRC  are  inputs  to  this  subroutine.  K is 
output  by  this  subroutine. 

5.10.2.2  Assumptions  and  Data  Sources 
(None) 

5.10.2.3  Equations 

Compute  distance  DIST  from  the  center  of  the  circle  to  the  point  on 
the  line  closest  to  the  center  of  the  circle. 

DIST  = ( (X3  - XX)2  + ( Y3  - YY)2)1/2 

where 

(X3,  Y3)  are  (X,  Y)  coordinates  of  circle  center 

(XX,  YY)  is  the  point  on  the  line  closest  to  circle  center 

5.10.3  Subroutine  CKL0SL(IX1,  IY1 , 1X2,  IY2,  1X3,  IY3,  1X4,  IY4,  K) 
5.10.3.1  Operation 

This  subroutine  determine  whether  two  line  segments,  defined  by 
(1X1,  IY1 ) , (1X2,  IY2)  and  (1X3,  IY3),  (1X4,  IY4),  intersect. 

If  an  intersection  exists,  K is  set  to  2;  otherwise,  K is  set  to  1. 
Parallel  line  segments  are  not  conisdered  to  intersect  even  if  they  are 
identical . 


Page  5-989 


Other  special  cases  are  handled  as  follows: 

. a)  If  either  line  segment,  but  not  both,  defines  a single  point,  the 
projection  of  the  point  on  the  line  segment  is  used  as  the  intersection 
poi nt. 


K = 1 


1X3,  IY3) 

= (1X4,  IY4) 


b)  If  both  line  segments  are  merely  single  points,  K = 1 is  returned 
unless  the  two  points  coincide. 

c)  Intersections  that  occur  on  end  points  of  line  segments  are  con- 
sidered to  be  valid  unless  the  two  line  segments  are  parallel. 

1X1,  IY1 , 1X2,  IY2,  1X3,  IY3,  1X4,  IY4  are  inputs  to  this  routine,  K is 
output  by  this  routine. 

5.10.3.2  Assumptions  and  Data  Sources 

It  is  assumed  that  no  intersections  will  occur  with  X or  Y values 
greater  than  the  magnitude  of  ±7999999. 

5.10.3.3  Equations 
(None) 

5.10.4  Subroutine  CKL0S2(IX1,  IY1 , 1X2,  IY2,  1X3,  1Y3,  1X4,  IY4,  IX,  IY,  K) 
5.10.4.1  Operation 

This  subroutine  computes  the  coordinates  of  the  point  of  intersection 
of  two  line  segments,  defined  by  ( I XI , I Y 1 ) , (1X2,  IY2)  and  (1X3,  I Y 3 ) , 
(1X4,  IY4).  It  returns  a flag  (K)  indicating  whether  or  not  an  intersec- 
tion exists.  IX  and  1Y  are  returned  with  the  coordinates  of  that  intersec- 
tion. K is  returned  with  value  2 if  the  intersection  calculated  lies 
within  the  X coordinates  of  the  two  segments;  otherwise,  K is  returned 
with  value  1.  All  special  cases  are  handled  as  with  subroutine  CKLOSL 
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(see  Section  5.10.3),  except  that  if  exactly  one  of  the  segments  is  para- 
llel to  the  X axis,  a K value  of  2 may  be  returned  even  if  the  segments 
do  not  intersect. 

1X1,  IY1 , 1X2,  IY2,  1X3,  IY3,  1X4,  IY4  are  inputs  to  this  routine  and  IX, 

IY,  and  K are  output. 

5.10.4.2  Assumptions  and  Data  Sources 

Same  as  subroutine  CKLOSL  (see  Section  5.10.3.2). 

5.10.4.3  Equations 
1X1  < IX  < 1X2 
1X3  < IX  5 1X4 

5.10.5  Subroutine  CK4XING 
5.10.5.1  Ope  ration 

Subroutine  CK4XING  has  two  main  purposes.  The  principal  of  these  is 
to  generate  an  alert  message  whenever  a control  measure  is  "violated". 

The  secondary  is  to  help  the  support  fire  allocation  logic  in  subroutine 
SPTAL0  to  avoid  automatic  support  fire  allocation  to  targets  which  would 
violate  firing  control  measures.  CATTS  as  delivered  to  Fort  Leavenworth 
had  automatic  support  fire  allocation  disabled  through  data  base  inputs; 
therefore,  this  secondary  purpose  has  never  been  thoroughly  tested  and 
has  never  been  used  in  an  exercise. 

Control  measures  in  CATTS  are  identified  by  two  "type"  numbers.  One 
of  these  is  just  a straightforward  listing  of  types  with  associated 
numbers.  This  is  called  the  "foreground"  control  measure  type,  as  it  is 
used  primarily  by  the  foreground  display  software.  The  other  "type"  is 
obtained  from  table  MTYP0FCM  by  subroutine  C0NTMS  at  the  time  the  mea- 
sure  is  created,  and  is  called  the  "background"  type,  as  it  is  used  by 
subroutine  CK4XING.  Both  numbers  are  stored  in  the  control  measure  table  I CM . 

The  background  "type"  is  similar  to  the  foreground  "type"  except  that  unused 
type  numbers  have  been  compressed  out  to  save  storage.  Also,  the  background 
"type"  is  set  to  zero  for  all  measures  for  which  no  alert  messages  are  to  be 
generated  (such  as  maneuver  routes).  Further,  a distinction  must  be  made  between 
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control  measures  for  movement  and  for  firing.  Therefore,  all  firing  con- 
trol measures  have  64  added  to  their  "type"  number.  But,  some  firing 
control  measures  may  not  be  fired  short  of  (in  other  words,  must  be  fired 
across).  In  order  to  distinguish  between  these,  those  measures  which 
must  be  fired  across  have  an  additional  64  (or  total  of  128)  added  to 
their  type  numbers. 

Each  control  measure  in  CATTS  must  also  belong  to  a "unit".  This 
unit  number  is  stored  in  the  table  ICM.  For  flexibility,  however,  "unit" 
has  been  expanded  to  include  operational  groupings  and  units  not  com- 
pletely modeled  (such  as  blue  division,  for  example). 

Each  "unit"  in  CATTS,  including  op  groups  and  imcompletely  modeled 
ones,  is  assigned  a next  higher  command  unit  by  the  table  NXHGCM.  A 
value  of  zero  is  possible  and  indicates  a unit  for  which  no  higher  command 
is  included  in  the  simulation. 

CK4XING  considers  a control  measure  to  apply  only  to  the  "unit"  to 
which  the  measure  is  assigned  at  creation  or  to  some  "unit"  which,  by  a 
chain  of  next  higher  command  values  from  NXHGCM,  is  subordinate  to  that 
assigned  "unit". 

The  actual  processing  for  CK4XING  begins  with  a call  which  specifies 
a unit  (IUNIT),  a source  point  (1X1,  IY1),  a destination  point  (1X2,  IY2), 
and  a flag  indicating  whether  the  calling  subroutine  is  concerned  with 
movement  ( IMFI RING  = 0)  or  firing  ( IMF  I RING  =1). 

The  first  step  is  the  construction  of  a table  NCOMM  which  lists  the 
complete  chain  of  command  for  unit  IUNIT.  The  next  step  is  to  cycle 
through  each  control  measure  in  the  model  table  ICM.  If  the  first  word 
of  the  measure  is  zero,  it  has  been  deleted  and  is  skipped.  If  the 
background  control  measure  "type"  as  explained  above  does  not  agree  with 
the  value  of  IMFIRING,  the  measure  is  skipped.  If  the  measure  is  red 
and  IUNIT  is  blue,  or  vice  versa,  the  measure  is  skipped  (a  measure  can 
belong  to  both  red  and  blue,  however).  If  the  measure  belongs  to  a 
"unit"  not  listed  in  table  NCOMM,  the  measure  is  skipped. 


Now  geometric  processing  begins.  If  the  minimum  or  maximum  X or  Y 
coordinates  (stored  in  table  ICM)  of  the  measure  are  such  that  the  line 
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segment  ( I XI , IY1)  to  (1X2,  IY2)  could  not  cross  the  measure,  then  the 
measure  is  skipped.  Otherwise,  the  line  segments  defining  the  control 
measure  are  unpacked  (even  control  points  are  modeled  as  small  areas) 
and  the  actual  number  (ICPOSS)  of  these  segments  which  cross  the  given 
segment  is  calculated  via  calls  to  subroutine  CKLOSL.  For  movement  mea- 
sures, alerts  are  generated  where  applicable  (an  odd  number  of  crossings 
is  required  to  generate  an  alert,  except  for  control  points) , and  pro- 
cessing is  complete  for  the  affected  measure.  For  firing  measures,  the 
control  measure  number  is  stored  in  table  MSRVIOL  if  it  has  been  violated. 
Whether  a violation  has  occurred  depends  on  whether  the  number  of  crossings 
is  even  or  odd  and  whether  this  type  of  measure  must  or  must  not  be  crossed. 
Processing  then  ends  for  this  measure. 

subroutine  CK4XING  terminates  processing  when  all  control  measures 
have  been  considered.  However,  it  has  an  entry  point,  CMFIRAL,  which 
is  called  when  firing  actually  occurs  in  violation  of  a measure.  CMFIRAL 
has, as  arguments, a unit  number  and  a control  measure  number  (from  the 
MSRVIOL  table  calculated  earlier)  and  generates  the  necessary  alert 
message  before  returning. 

5.10.5.2  Assumptions  and  Data  Sources 

(None  which  are  not  implicit  in  the  operation  description.) 

5.10.5.3  Equations 
(None) 


5.10.6  Subroutine  CMSEGMNT  ( I UN  I T , K,  ISEGMENT,  IRETURN,  ICNTRLX , ICNTRLY) 
5.10.6.1  Operation 


This  routine  finds  and  unpacks  the  next  destination  point  for  a ground 
unit  traveling  on  an  existing  route  (existing  routes  are  modeled  as  con- 
trol measures). 


Input:  I UN  IT 

K 


= number  of  unit. 

= number  of  control  measure  which  represents 
route  being  traveled  by  IUNIT. 


ISEGMENT  = number  of  the  line  segment  on  control  measure 
K which  IUNIT  has  just  completed  traversing. 
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I RETURN 

= 0 is  the  normal  case  when 
has  been  found. 

the  next  point 

ICNTRLX  ) 

_ (X,  Y)  coordinates  of  next 

destination  point 

ICNTRLY  j 

( i f any) . 

5.10.6.2  Assumptions  and  Data  Sources 

Existing  ground  movement  routes  are  modeled  as  special  control  mea- 
sures, and  stored  in  table  ICM. 

5.10.6.3  Equations 
(None) 

5.10.7  Subroutine  DESTIN 

5.10.7.1  Operation 

DESTIN  performs  a standard  coordinate  rotation  and  translation  of 
input  point  P = (1X2,  IY2).  P is  first  rotated  by  an  angle  defined  by 
sine  and  cosine  ST  and  CT  respectively.  It  is  then  translated  by 
= (1X1,  I Y 1 ) to  give  the  resultant  point  (1X3,  IY3).  This  is  performed 
via  calls  to  1TRANS. 

5.10.7.2  Assumptions  and  Data  Sources 
(None) 

5.10.7.3  Equations 
(None) 

5.10.8  Subroutine  FIRAGEN 
5.10.8.1  Ope  ration 

Called  once  per  timestep  to  maintain  tables  which  keep  track  of  which 
units  are  firing  which  types  of  weapons  at  which  other  units.  Also  main- 
tains tables  which  give  casualty  levels  since  last  report.  The  sole  pur- 
pose of  these  tables  and  of  this  routine  is  to  determine  when  alert 
messages  should  be  generated,  and  to  generate  those  messages. 

The  first  type  of  alert  message  is  generated  whenever  a unit  starts 
firing  or  receiving  fire  in  any  of  the  following  categories:  direct  fire, 

indirect  fire,  support  fire.  The  tables  controlling  this  alert  are  0LDFLG, 
which  describes  the  situation  last  timestep,  and  N0WFLG,  which  describes 
the  current  timestep.  An  alert  is  generated  when  NOwrLG  indicates  that  a 
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unit  is  now  firing  (or  receiving)  a class  of  fire  which  OLDFLG  indicates 
it  was  not  firing  (or  receiving)  last  timestep. 

The  second  type  of  alert  message  is  a casualty  report.  This  message 
is  generated  whenever  a unit  which  was  under  fire  receives  no  fire  at  all 
for  a full  timestep,  and  reports  total  men  and  equipment  casualties  for 
the  engagement.  It  is  also  generated  whenever  casualties  incurred  since 
the  last  casualty  report  exceed  an  input  threshold.  For  equipment  type 
IEQ,  input  variable  I ECTH  (IEQ)  gives  the  number  of  pieces  of  that  equip- 
ment which,  when  lost,  will  be  sufficient  to  generate  a casualty  alert. 
Input  variable  PCTH  specifies  the  fraction  of  personnel  which,  when  lost, 
will  be  sufficient  to  generate  a casualty  alert. 

The  actual  functioning  of  FIRAGEN  is  straightforward  but  tedious, 
since  most  of  the  tables  involved  are  packed,  and  therefore  accessed 
with  assembly  language. 

5.10.8.2  Assumptions  and  Data  Sources 
(None) 

5.10.8.3  Equations 
(None) 

5.10.9  Function  IRND(X) 

5.10.9.1  Operation 

This  function  adds  +.5  or  -.5  to  a floating  point  number,  X,  depend- 
ing on  whether  the  number  is  positive  or  negative,  respectively,  and  out- 
puts the  results  in  its  integer  truncated  value. 

5.10.9.2  Assumptions  and  Data  Sources 
(None) 

5.10.9.3  Equations 
IRND  = Xt.5 
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5.10.10  Function  ISFIROR(IU) 

5.10.10.1  Operation 

This  function  searches  the  fire  override  table  (array  IFIROVRD  in 
common  block  FIROVRD)  for  a reference  to  unit  number  IU.  If  a reference 
to  IU  is  found,  a 2 is  returned.  If  such  a reference  is  not  found,  a 1 
is  returned. 

5.10.10.2  Assumptions  and  Data  Sources 

It  is  assumed  that  entries  in  IFIROVRD  are  packed  in  bytes  in  ascend- 
ing order. 

5.10.10.3  Equations 
(None) 

5.10.11  Function  I TRANS (K1 , XI,  K2,  X2) 

5.10.11  .1  Operation 

This  function  performs  a calculation  frequently  used  in  coordinate 
transformation . The  calculation  consists  of  converting  the  integerized 
coordinate  point  (K1  and  K2)  to  floating  point  numbers,  multiplying  each 
by  floating  point  numbers  (XI  and  X2,  respectively),  summing  the  products 
and  converting  the  result  to  integer  form  by  calling  IRND. 

The  standard  geometry  rotation  formulas  that  this  function  uses  are: 

X1  = XCOS0  + YSIN0  or  X1  = ITRANS( IX,  COS(o),  IY,  SIN(o) ) 

Y1  = YCOSe  - XSINO  or  Y1  = ITRANS(IY,COS(0) , - IX,  SIN(e) 

X = x^ose  - Y 1 S INo 

Y = Y^OSe  + X 1 S I N 0 

where  primed  letters  designate  new  coordinates,  and  0 is  the  angle  of 
rotation . 

5.10.11.2  Assumptions  and  Data  Sources 
(None) 

5.10.11  .3  Equations 

ITRANS  = K1  * XI  + K2  * X2 


L ■ — — - - ^ 


5.10.12  Subroutine  LATDST ( I ,K) 

5.10.12.1  Operation 
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This  subroutine  makes  use  of  subroutine  PLDST2  to  calculate  the  per- 
pendicular lateral  distance  of  unit  I from  the  axis  of  engagement  K.  The 
calculated  distance  added  to  the  unit's  half-frontage  is  used  to  replace 
engagement  K's  half-frontage  if  it  is  larger  than  the  existing  half-frontage. 
If  the  unit  is  in  the  process  of  deploying,  the  distance  is  calculated  from 
the  deployment  point  to  the  engagement  axis. 

5.10.12.2  Assumptions  and  Data  Sources 
(None) 

5.10.12.3  Equations 
(None) 

5.10.13  Subroutine  LL1NT (A1 , Bl,  A2,  32,  IX,  IY) 

5.10.13.1  Operation 

This  subroutine  computes  the  coordinates  (IX,  IV)  of  the  intersec- 
tion of  two  lines,  which  are  defined  in  slope-intercept  form:  Yl  = A1  x 
XI  + Bl  and  Y2  = A2  x X2  + B2.  The  intersection  is  obtained  by  the  simul- 
taneous solution,  by  algebraic  means,  of  the  two  equations  and  is  then 
integerized.  If  the  two  slopes  are  equal,  IX  and  1Y  are  set,  respectively, 
equal  to  -7999999  and  +7999999,  for  a negative  slope,  and  to  +7999999  and 
+7999999,  for  a positive  slope. 

5.10.13.2  Assumptions  and  Data  Sources 
(None) 

5.10.13.3  Equations 

IX  = (B2  - Bl )/ ( A 1 - A2) 

IY  = A1  * IX  + Bl 

5.10.14  Subroutine  LLINT1 ( 1X1 , IY1,  1X2,  IY2,  1X3,  IY3,  1X4,  IY4,  IX,  IY) 
5.10.14.1  Operation 

This  subroutine  calculates  the  point  of  intersection  of  two  lines, 
each  defined  by  two  points. 
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If  either  line  is  really  a point  (defining  points  co-located),  its  slope 
is  set  equal  to  the  negative  inverse  of  the  other  line's  slope,  thus, 
projecting  the  point  (line  1)  onto  the  second  line.  Once  the  special 
cases  above  have  been  checked  for  and  treated,  the  first  and  second  lines 
are  both  converted  to  the  slope-intercept  form,  and  calculated  as  in 
Subroutine  LLINT,  of  Section  5.10.13. 

5.10.14.2  Assumptions  and  Data  Sources 

It  is  assumed  that  no  intersections  will  occur  with  X or  Y values 
greater  than  the  magnitude  of  ±7999999. 

5.10.14.3  Equations 

A1  = FLOAT ( I Y2  - IY1 )/FL0AT( 1X2  - 1X1) 

Line  1 & 2 intercept  equations  are: 

B1  = FL0AT( IY2)  - FL0AT(IX2)  (A1 ) 

B2  = FLOAT ( IY2)  - FL0AT(IX3)  (A2) 

5.10.15  Subroutine  LLINT2(IX1,  IY1 , 1X2,  IY2,  1X3,  IY3,  A2,  IX,  IY) 

5.10.15.1  Operation 

This  subroutine  computes  the  coordinates  (IX,  IY)  of  the  intersection 
of  two  lines,  the  first  defined  by  the  two  points  ( I X 1 , IY1),  (1X2,  IY2) 
and  the  second  defined  by  point  (1X3,  I Y 3 ) and  slope  A2.  This  is  done 
by  calculating  the  slope  of  line  one  and  the  Y-intercepts  of  each  line 
and  proceeding  as  in  Subroutine  LLINT,  of  Section  5.10.13. 

5.10.15.2  Assumptions  and  Data  Sources 

It  is  assumed  that  no  intersections  will  occur  with  X or  Y values 
greater  than  the  magnitude  of  ±7999999. 

5.10.15.3  Equations 

The  Y intercepts  of  both  lines  are  calculated  via: 

B1  = IY1  - I XI  * A1 


B2  = IY3  - 1X3  * A2 
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5.10.16  Subroutine  LL I NT3 ( 1X1 , IY1,  1X2,  IY2.  A1 , A2,  IX,  IY) 

5.10.16.1  Operation 

This  subroutine  computes  the  coordinates  (IX,  IY)  of  the  intersection 
of  two  lines,  LI  and  L2,  each  defined  by  one  point  and  slope,  I X 1 , IY1,  A1 
and  1X2,  IY2,  A2,  respectively.  The  Y-i ntercepts  are  first  computed  for  each 
line.  Subroutine  HINT  is  then  caleed  to  compute  the  intersection  point  of 
the  lines  from  the  slope-intercept  form,  Y = AX  + B. 

5.10.16.2  Assumptions  and  Data  Sources 
(None) 

5.10.16.3  Equations 
(None) 

5.10.17  Subroutine  LOADSEG 

5.10.17.1  Operation 

This  subroutine  performs  2 functions: 

1)  It  saves  the  overlay  segment  number  (as  the  first  word  of 
common  block  JTRAP,  i.e.,  NUMSEG)  of  the  overlay  segment 
about  to  be  loaded  into  core.  This  is  done  so  that  if  a 
model  trap  occurs,  the  user  will  be  able  to  tell  which 
segment  of  code  was  being  executed.  See  "Core  Dump  Pro- 
cedure When  Math  Model  Traps"  in  the  Data  Base/Operations 
Manual . page  240. 

2)  It  calls  the  Xerox  library  subroutine  SEGLOAD(NUMSEG)  to 
load  the  overlay  segment  into  core. 

5.10.17.2  Assumptions  and  Data  Sources 

That  the  user  would  like  to  know  which  overlay  segment  is  executing 
in  core  when  a trap  occurs.  TRW  engineering  estimate  by  R.  Lew. 

5.10.17.3  Equations 


( None) 
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5.10.18  Subroutine  LOWALERT 

5.10.18.1  Ope  ration  V 

Called  once  pe--  timestep  to  generate  any  alert  messages  necessary  to 
indicate  any  of  the  following  for  non-defunct  ground  units: 

1)  Low  gasoline  level  in  a unit. 

2)  Low  diesel  level  in  a unit. 

3)  Significant  change  in  rate  of  movement  for  a unit. 

4)  Unit  halted  by  an  obstacle. 

5)  Casualties  caused  by  minefield. 

6)  Low  ammunition  level  in  a unit. 

The  three  low  level  alerts  (gasoline,  diesel,  and  ammunition)  are 
generated  the  first  timestep  that  current  levels  (CLGAS,  CLDIES,  NETAMU) 
for  a unit  fall  below  input  fractions  (REVGAS,  REVDIES,  AMOREV)  times  ini- 
tial levels  (BLGAS,  BLDIES,  NETAMX) . When  a,  low  level  alert  is  generated, 
a flag  is  set  in  a table  (IGASF,  IDIESF,  IAMOALF)  to  indicate  the  issuance 
of  the  alert.  No  further  alerts  of  the  same  kind  will  be  issued  as  long 
as  the  flag  is  set,  and  the  flag  is  cleaned  only  when  a Resupply  event  is 
accepted  for  the  affected  unit  (whether  or  not  the  resupply  includes  the 
needed  item). 

The  alert  for  significant  movement  rate  change  occurs  whenever  the  new 
movement  rate  (ROMU)  for  a unit  differs  from  the  rate  last  timestep  (BROMU) 
by  either  an  input  threshold  amount  (DELMNT),  or  an  input  threshold  fraction 
(UELMOVE)  times  the  old  rate  (BROMU).  This  alert  is  also  generated  whenever 
a unit's  movement  (from  tables  M0UNT0LD  and  MOUNTED)  changes  from  mounted 
to  dismounted,  or  vice  versa,  regardless  of  the  rates  involved. 

Alerts  for  units  stopped  by  obstacles  are  generated  based  on  flags  set 
by  the  obstacle  model  in  tables  I0BALRT  and  I0BST0P.  Alerts  for  minefield 
casualties  are  generated  only  when  an  alert  has  been  issued  for  being 
stopped  by  an  obstacle  which  is  a minefield.  The  casualties  reported  are 
obtained  from  tables  KLDPPL  and  NTPEQDST,  both  set  by  the  obstacle  model. 

5.10.18.2  A sumptions  and  Data  Sources 


(None ) 
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5.10.18.3  Equations 
(None) 

5.10.19  Function  MANNING( IEQ.IU) 

5.10.19.1  Operation 

This  function  returns  the  number  of  personnel  required  to  operate  a 
given  type  of  equipment  in  a given  unit  (IU)  as  a function  of  the  unit's 
travel  mode.  The  byte-packed  array  OPE  for  equipment  IEQ  is  unpacked  to 
return  the  crew  size  required  for  the  operation  of  the  equipment  in  the 
mounted  or  dismounted  mode  and  its  troop-carrying  capacity.  The  crew 
size  returned  is  that  for  the  dismounted  mode,  unless  the  equipment  is 
a vehicle  in  a unit  moving  in  the  mounted  mode.  In  this  case,  the  crew 
size  refers  to  the  mounted  mode  of  the  equipment. 

5.10.19.2  Assumptions  and  Data  Sources 
(None) 

5.10.19.3  Equations 
(None) 

5.10.20  Subroutine  NEWL0C(IX1,  IY1,  ST,  CT,  IDIST,  1X2,  IY2) 

5.10.20.1  Operation 

Calculates  coordinates  of  the  point  (1X2,  IY2)  reached  by  traveling 
a distance  IDIST  from  the  point  ( I X 1 , I Y 1 ) in  the  direction  with  sine  and 
cosine  equal  ST  and  CT,  respectively. 

5.10.20.2  Assumptions  and  Data  Sources 
(None) 

5.10.20.3  Equations 

1X2  = 1X1  + CT - IDIST 


IY2  = IY1  + ST • IDIST 
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5.10.21  Function  NXUNITf IUN IT) 

5.10.21.1  Operation 

Given  a unit,  I UN  IT , this  function  returns  the  unit  number  of  the 
next  unit  appearing  on  the  unit  list.  The  number  is  obtained  by  unpacking 
the  right-most  byte  of  variable  L I STUN ( IUN IT) . 

5.10.21.2  Assumptions  and  Data  Sources 
(None) 

5.10.21.3  Equations 
(None) 

5.10.22  Subroutine  PLDST2( 1X1 , IY1,  ST,  CT,  1X3,  IY3,  IDIST) 

5.10.22.1  Operation 

This  subroutine  computes  the  closest  distance  between  a line,  L,  and 
a point,  P3.  Inputs  to  the  subroutine  are  the  description  of  Line  L, 
defined  by  a point  ( I X 1 , I Y 1 ) , the  sine(ST)  and  cosine(CT)  of  the  line's 
positive  angle  with  the  X-axis,  and  the  point  P3  (1X3,  IY3).  The  com- 
puted distance  is  the  output  (HOST).  This  routine  makes  use  of  subrou- 
tine PLPRJ2  to  compute  the  closest  point  on  L to  P3.  If  ST  and  CT  are 
the  sine  and  cosine  of  angle  theta  (u),  the  value  of  IDIST  is  computed 
as  in  the  following  diagram: 


I 
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5.10.22.2  Assumptions  and  Data  Sources 
(None) 

5.10.22.3  Equations 

Given  the  closest  point  (1X2,  IY2)  on  L to  P3,  the  distance  between 
(1X2,  IY2)  and  (1X3,  IY3)  is  calculated  via: 

IDIST  = ((1X3  - IX2)2  + (IY3  - IY2)2)1/2 

5.10.23  Subroutine  PLINE(LINE,N) 

5.10.23.1  Operation 

This  I/O  routine  outputs  N lines  contained  in  buffer  LINE  to  the 
line  printer  device  using  the  asynchronous  foreground  line  printer  con- 
trol program  PRINTQ.  The  routine  calculates  successively  the  starting 
address  of  each  136  character  line  buffer  (the  first  character  is  car- 
riage control)  and  passes  each  line  to  the  foreground  PRINTQ  program 
via  a constructed  CAL4,  1. 

5.10.23.2  Assumptions  and  Data  Sources 
(None) 

5.10.23.3  Equations 
(None) 

5.10.24  Subroutine  PLPRJ1 ( 1X1 , IY1 , 1X2,  IY2,  1X3,  IY3,  IX,  IY) 

5.10.24,1  Operation 

This  subroutine  calculates  the  projection  of  a point,  (1X3,  I Y 3 ) , 
on  a line  L,  defined  by  two  points,  ( I X 1 , I Y 1 ) and  (1X2,  IY2).  The  result 
is  returned  via  IX  and  IY.  The  slope,  A1 , of  line  L is  first  computed. 
Then,  the  slope  (A2)  of  a line  perpendicular  to  L and  going  through  point 
(1X3,  IY3)  is  defined  by  the  negative  reciprocal  of  slope  A1 . Finally, 
the  intersection  point  of  the  line  defined  by  (1X3,  1Y3)  and  A2  with  L is 
computed.  The  following  diagram  illustrates  the  results  obtained: 
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5.10.24.2  Assumptions  and  Data  Sources 
(None) 

5.10.24.3  Equations 

IX  = (B2  - B1)/(A1  - A2) 

IY  = A1  * IX  + B1 

where  B1  is  the  Y-intercept  of  L and  B2  is  the  Y-intercept  of  the 
line  perpendicular  to  L passing  through  (1X3,  IY3). 

5.10.25  Subroutine  PLPRJ2(IX1,  IY1 , 1X3,  IY3,  ST,  CT,  IX,  IY) 

5.10.25.1  Operation 

This  subroutine  computes  the  coordinate  of  the  projection  of  a point 
(1X3,  IY3)  on  a line  (L)  defined  by  a point  (1X1,  IY1)  and  the  sine(ST) 
and  cosine(CT)  of  its  positive  angle  (e)  with  the  X-axis.  If  line  L is 
parallel  to  either  coordinate  axis,  the  coordinates  of  the  projection  of 
the  point  on  the  line  are  assigned  immediately.  Otherwise,  the  slope  of 
a line  perpendicular  to  L and  through  point  (1X3,  IY3)  is  defined  by  th 
negative  reciprocal  of  the  slope  of  line  L.  The  intersection  point  (IX,  IY) 
is  then  calculated.  The  following  diagram  illustrates  the  results 
obtained: 
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5.10.25.2  Assumptions  and  Data  Sources 
(None) 

5.10.25.3  Equations 
A1  = ST/CT 
A2  = -1/A1 

IX  = (B2  - B1 )/(Al  - A2) 

IY  = A1  * IX  + B1 

where  B1  is  the  Y-intercept  of  L and  B2  is  the  Y-intercept  of  the 
line  perpendicular  to  L passing  through  (1X3,  IY3). 

5.10.26  Subroutine  PPANGL(IX1,  IY1 , 1X2,  IY2,  ST,  CT) 

5.10.26.1  Operation 

This  subroutine  computes  the  sine(ST)*and  the  cosine(CT)  of  the 
angle  (e)  formed  by  a line  L and  the  X-axis.  Line  L is  defined  by  two 
points,  ( I X 1 , IY1)  and  (1X2,  IY2).  First,  the  two  points  are  tested  for 
co-location.  If  they  are  co-located,  ST  and  CT  are  set  equal  to  zero; 
otherwise,  the  distance  between  the  two  points  is  computed.  This  dis- 
tance is  then  used  to  compute  ST  and  CT.  The  following  diagram  illus- 
trates the  results  obtained; 
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5.10.28  Subroutine  PRNTFIR 

5.10.28.1  Operation 

This  subroutine  prints  the  firing  report  which  gives  detailed  informa- 
tion regarding  the  number  of  rounds  of  fire  allocated  to  each  target  for 
each  weapon  in  each  unit.  Input  variables  IUCOD  and  IWCOD  allow  the  user 
to  select  only  certain  units  or  weapons  to  be  reported  on.  Operation  is 
straightforward.  IUCOD  and  IWCOD  are  bit  packed  tables,  and  must  be  unpacked 
for  comparison  with  firing  unit  I and  weapon  IBETA. 

5.10.28.2  Assumptions  and  Data  Sources 
(None) 

5.10.28.3  Equations 
(None) 

5.10.29  Subroutine  REDCON 
5.10.29.1  Operation 

This  subroutine  is  called  once  per  timestep  to  compute  unit  readiness 
condition  (REDCON)  for  each  non-defunct  ground  unit.  Alert  messages  are 
generated  for  any  change  in  readiness  condition,  so  long  as  that  condition 
is  not  less  than  user  input  MNREDCON.  Computations  and  criteria  required 
for  the  determination  of  unit  readiness  are  specified  in  the  Unit  Commanders 
Handbook  of  the  USAIS.  There  are  six  categories  of  readiness  contributing 
to  the  overall  unit  REDCON.  These  are: 

1)  Operating  Strength 

2)  Military  Occupational  Specialty 

3)  Training 

4)  Equipment  On  Hand 

5)  Equipment  Status 

6)  Missile  Systems  Availability 

Of  the  above  readiness  categories  only  operating  strength,  equipment  on 
hand  and  equipment  status  provide  readiness  factors  that  are  meaningful  to 
the  CATTS  model.  The  overall  REDCON  of  a particular  unit  is  defined  as 
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the  minimal  readiness  conditions  of  the  three  readiness  categories.  Each 
category  is  evaluated  with  respect  to  the  criteria  given  in  Table  5-64.  The 
evaluation  will  produce  one  of  the  following  readiness  indicators  for 
each  category: 

1)  Unit  is  fully  ready  to  perform  its  assigned  mission. 

2)  Unit  is  substantially  ready  to  perform  its  assigned  mission. 

3)  Unit  is  marginally  ready  to  perform  its  assigned  mission. 

4)  Unit  is  not  ready  to  perform  its  assigned  mission. 

There  is  an  optional  capability  available  to  the  user  to  have  ammuni- 
tion levels  included  in  the  readiness  calculation  in  a manner  identical  to 
equipment.  This  is  controlled  by  user  input  IREDAMMO.  "Zero"  means  do 
not  include  ammunition  levels;  "one"  means  do  include  them. 

5.10.29.2  Assumptions  and  Data  Sources 

Readiness  conditions  will  be  computed  as  in  USAIS  Unit  Commanders 
Handbook , except  that  the  following  criteria  are  not  used  in  the  model: 

1)  Military  Occupational  Specialty 

2)  Training  Level  of  Personnel 

3)  Missile  Systems  Availability 

5.10.29.3  Equations 
(None) 

5.10.30  Subroutine  REDIST 
5.10.30.1  Operation 

This  subroutine  redistributes  personnel  to  the  remaining  equipment  in 
each  unit.  It  is  executed  once  each  model  timestep.  It  uses  table  STATS 
and  its  detailed  operation  is  shown  in  Figure  5-147.  The  general  rationale 
for  this  subroutine  is  to  provide  a means  whereby,  as  casualties  are  in- 
curred, sufficient  personnel  are  assigned  to  operate  the  highest  priority 
(i.e.,  most  lethal)  equipment  in  each  unit.  For  example,  as  tank  crew  per- 
sonnel become  casualties  (but  not  the  tank),  unit  personnel  manning  lower 
priority  equipment,  say  rifles,  will  be  reassigned  as  tank  crew  members.. 
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Figure  5-147.  REDIST  FLOW  DIAGRAM 
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Figure  5-147.  REDIST  FLOW  DIAGRAM  (CONT'D) 
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Figure  5-147.  REDIST  FLOW  DIAGRAM  (CONT'D) 
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Certain  exceptions  are  taken  under  special  conditions  as  discussed  in  the 
assumptions  and  data  sources  section. 

5.10.30.2  Assumptions  and  Data  Sources 

The  assumptions  used  in  constructing  Subroutine  REDIST  are  described 
below.  Most  of  these  assumptions  were  defined  during  planning  conferences 
with  U.S.  Army  CATTS  Project  personnel.  All  input  data  relative  to  vehicle 
crew  sizes  for  mounted,  dismounted,  and  troop  carrying  capacity  were  ex- 
tracted from  applicable  U.S.  Army  Field  Manuals  and  USAIS  training  texts. 

1)  Only  an  integer  number  of  equipment  is  manned  at  all  times. 

2)  Mounted  and  dismounted  travel  mode  operations  are  accounted  for. 

3)  Each  equipment  is  assigned  three  different  manning  levels: 

• Minimum  crew  size  when  operated  in  mounted  mode. 

s Minimum  crew  size  when  operated  ir.  dismounted  mode. 

• Maximum  troop  carrying  capacity. 

4)  Support  fire  weapons  in  a unit  receive  manning  priorities  degraded 
by  an  input  quantity  whenever  the  unit  is  under  fire  from  direct 
fire  weapons,  unless  the  weapon  is  self-propelled  and  the  unit 

is  moving,  in  which  case  the  manning  priority  remains  unchanged. 

This  is  so  because  the  crew  required  to  drive  such  a weapon  to 
safety  is  smaller  than  the  crew  required  to  fire  it  and,  pre- 
sumably, every  effort  would  be  made  to  drive  the  weapon  to  safety. 

5)  Dismounted  movement  rates  are  achieved  by  identifying  certain  equip- 
ment, such  as  rifles,  as  being  operable  only  when  the  operator  is 
dismounted,  and  assigning  these  equipments  reasonable  dismounted 
rates  of  movement.  This  has  the  effect  of  slightly  decreasing  the 
total  fire  power  of  a mounted  unit. 

6)  In  a unit  given  C&C  to  move  in  mounted  mode,  no  dismounted-only 
equipment  is  manned  unless  vehicle  troop  carrying  capacity  of  the 
unit  is  less  than  the  current  personnel  level.  In  this  case, 
leftover  personnel  are  assigned  to  dismounted-only  equipment, 
according  to  the  normal  input  priority  scheme  and  the  unit  is 
allowed  to  move  only  at  the  dismounted  movement  rate. 

7)  Units  which  are  unable  to  man  all  of  their  vehicles  will  abandon 
unmanned  vehicles  if  the  unit  is  moving. 

8)  Units  given  C&C  to  move  in  a dismounted  mode  will  have  personnel 
assigned  strictly  by  the  input  priority  scheme,  with  consequences 
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as  follows:  If  no  foot  equipment  is  manned,  then  the  unit  will 

move  at  mounted  rates,  while  any  unmanned  vehicles  will  be 
abandoned  and  lost. 

9)  Alerts  are  generated  and  presented  on  the  alpha-numeric  display 
whenever  the  actual  mode  of  travel  changes.  Alerts  for  starting/ 
halting  movement  include  the  mode  actually  employed  by  the  unit. 

10)  Sensors  such  as  radars  are  not  manned  by  units  moving  in  a mounted 
mode.  However,  it  is  possible  to  man  both  tanks  and  sensors  in  a 
tank  platoon  when  it  is  stationary  (hence,  technically  dismounted 
by  model  definitions)  by  setting  dismounted  crew  size  to  three 
instead  of  four.  Note  that  some  sensors,  such  as  ground  radars, 
are  not  considered  operable  by  any  moving  unit. 

11 ) The  model  assumes  that  all  non-vehicular  equipment  and  ammunition 
can  be  carried  around  by  the  unit  at  all  times,  regardless  of 
whether  this  would  actually  be  possible. 

12)  A unit  which  has  just  enough  vehicular  capacity  to  carry  its 
personnel  may  change  from  mounted  to  dismounted  travel  if  it 
lost  a vehicle,  and  then  back  to  mounted  if  it  lost  personnel, 
all  within  a short  time. 

13)  A weapon  for  which  a unit  runs  out  of  ammunition  is  manned  only 
when  all  other  equipment  is  manned,  unless  the  weapon  is  also  a 
vehicle  and  the  unit  is  moving,  in  which  case  its  manning  prior- 
ity remains  unchanged. 

14)  Under  circumstances  other  than  those  outlined  above,  personnel 
assignments  are  made  strictly  according  to  input  priority  schemes. 

15)  Of  two  equipment  categories  which  receive  equal  manning  priorities, 
all  equipment  in  the  category  which  appears  first  in  the  model's 
equipment  list  for  that  unit  is  manned  before  any  of  the  category 
which  appears  second.  Careful  selection  of  manning  priorities  by 
the  user  can  prevent  the  occurrence  of  ties  in  priority. 

16)  The  model  will  behave  oddly  under  special  situations  such  as  for 
units  which  do  not  have  enough  equipment  available  to  man.  Un- 
assigned personnel  are  invulnerable  to  fire  for  the  time  they  re- 
main unassigned.  Since  movement  rates  arc  computed  as  a function 
of  the  manned  equipment  types  in  a unit,  a unit  with  no  equipment 
whatsoever  is  unable  to  move.  A unit  which  has  only  one  vehicle 
and  no  other  equipment  moves  at  mounted  rates  since  it  contains 
no  dismounted  equipments. 

5.10.30.3  Equations 

The  equations  presented  in  the  code  for  this  subroutine  are  reasonably 
simple  and  straight-forward  and  are,  therefore,  not  described  in  this  section. 
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5.10.31  Subroutine  STEP 


5.10.31.1  Operation 

STEP  is  called  once  per  t i me  step  to  perform  a wide  variety  of  book- 
keeping and  miscellaneous  tasks. 

The  first  thing  STEP  does  is  loop  over  all  active  ground  units.  For 
each  of  these  units,  the  following  things  are  done: 

• For  each  unit  which  neither  fired  nor  received  fire  (IFIRRL),  the 
mode  selection  table  range  (MUSLRA)  is  set  to  7999999. 

• For  each  unit  with  personnel  casualties  (DPERS)  non-zero  during 
the  current  timestep,  the  casualties  are  integerized  (see 
Assumptions)  and  subtracted  from  current  levels  (PERS).  Next, 
the  casualties  are  distributed  over  the  four  personnel  types  of 
CO,  officers,  enlisted  leaders,  and  enlisted  (MENN0W).  Then 
the  casualties  are  distributed  over  the  personnel  vulnerability 
classes  (PERNVC)  based  on  input  weighting  factors  (WTFCTR) . 

• Each  equipment  in  the  unit  is  processed  through  the  maintenance 
attrition  model  (see  Assumptions)  based  on  input  MTBF  numbers 
(DTMTBFI).  Any  "broken"  equipment  is  subtracted  from  current 
levels  (TOTEQU)  and  added  to  post-game  statistics  (STATS). 

• Any  unit  with  personnel  level  (PERS)  zero  is  made  defunct  by 
setting  certain  of  its  variables,  such  as  status  (ISTATU). 

• Personnel  vul nerabi 1 i ty  distribution  (PERNVC)  for  the  current 
timestep  is  moved  to  the  last  timestep  storage,  and  "current" 
storage  is  zeroed. 

• The  weight  of  the  unit  as  a personnel  target  (PERSWT)  is  calcu- 
lated based  on  vulnerability  distribution  (PERNVC)  and  input 
weighting  factors  (WPVC). 

This  ends  processing  for  the  unit  loop.  The  next  series  of  actions 
taken  is  successive  calls  to  FIRAGEN,  REDCON,  LOWALRT,  and  DEADCP  (a  local 
subroutine  containing  the  logic  for  temporary  loss  of  communications  caused 
by  destruction  of  a command  and  control  headquarters) . FIRAGEN,  REDCON,  and 
LOWALRT  are  individually  described  in  Section  5.10. 

Local  subroutine  DEADCP  first  checks  an  input  flag  (NODlADCP)  to 
determine  whether  the  user  has  disabled  the  model  for  loss  of  communica- 
tions caused  by  destruction  of  a command  and  control  headquarters.  Then 
it  cycles  through  all  non-defunct  ground  units.  Each  is  checked  to  see  if 
it  is  a command  post  (variable  ISIZE)  of  at  least  a user  input  command 
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level  (variable  MNSIZECP) . For  example,  if  MNSIZECP  were  -5,  then  only 
battalion  and  higher  command  post  units  (ISIZE  5 -5)  would  be  eligible  for 
loss  of  communications . Those  units  eligible  are  then  checked;  if  per- 
sonnel level  (PERS)  divided  by  initial  level  (PERSI)  is  less  than  a user 
input  threshold  (CPDEADP),  then  an  alert  is  generated  and  communications 
are  lost  for  an  input  number  of  minutes  (NOPEADCP)  by  incrementing  the 
lost  communications  table  (IMDEADCP).  Alternatively,  if  personnel  levels 
are  still  satisfactory,  the  total  levels  of  fuel  consuming  (EQCAPAC  > 0) 
equipments  in  the  unit  are  accumulated  into  an  initial  level  total  and  a 
current  level  total.  If  current  level  total  divided  by  initial  level 
total  is  less  than  a user  input  threshold  (CPDEADV),  then  an  alert  is 
issued  and  communications  are  lost  for  NODEADCP  minutes.  This  completes 
processing  for  local  subroutine  DEADCP . 

After  invoking  DEADCP,  subroutine  STEP  updates  and  zeroes  out  a 
number  of  tables.  NOWFLG  values  are  moved  to  OLDFLG,  then  NOWFLG  is 
zeroed.  IADWUNIT  is  zeroed.  I UN IM  and  IUNIMXY  are  updated  to  reflect 
current  impacting  fires.  This  completes  processing  for  subroutine  STEP. 

5.10.31.2  Assumptions  and  Data  Sources 

Whenever  a fractional  number  F of  (men  or  equipment)  casualties  are 
calculated  by  the  Fire  Module,  a pseudo-random  number  R is  generated  and 
compared  with  F.  If  R is  less  than  F,  then  one  casualty  has  occurred, 
otherwise  none.  Any  integral  number  of  casualties  calculated  are  simply 
decremented  from  existing  levels.  Thus,  for  example,  if  1.6  casualties 
were  calculated,  60%  of  the  time  two  casualties  would  result,  and  40% 
of  the  time  only  one. 

Maintenance  attrition  in  CATTS  is  modeled  using  the  familiar  Poisson 
probability  of  no  failure  in  time  interval  At: 

P(f ) = e-r|/ 

where  n = total  number  of  pieces  of  equipment  in  use 
d = mean  time  between  failures  (MTBF). 

The  number  actually  used  by  CATTS  is  and  is  user  input  as 

DTMTBFI  for  each  equipment  type. 
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5.10.31.3  Equations 
(None ) 

5.10.32  Subroutine  STRIP 

5.10.32.1  Operation 

This  subroutine  is  used  to  strip  packed  information  from  a code  word  by 
dividing  it  by  an  appropriate  power  of  10,  thereby  stripping  off  the  high 
order  information  contained  in  the  word.  By  successive  calls,  the  entire 
word  may  be  broken  down.  The  subroutine  receives  the  values  of  ISAVEl  and 
KONST  through  the  labeled  COMMON/S/;  it  then  calculates: 

ITEST1  = I SAVE1 / KONST 
and  ISAVEl  = ISAVEl  - ITEST1  * KONST 

The  calculated  values  of  ITEST1  and  ISAVEl  are  returned  through  COMMON/S/. 

5. 1C. 32. 2 Assumptions  and  Data  Sources 
(None) 

5. 1C. 32. 3 Equations 

(None  of  any  significance) 

5.10.33  Subroutine  UN2FEB( IDUM , 1X3,  IY3) 

5.10.33.1  Operation 

This  is  a service  routine  whose  purpose  is  to  find  the  final  destina- 
tion X.  Y coordinates  (1X3,  IY3)  for  a unit  IDUM,  with  movement  code 
(MVTCD( IDUM) ) 11  or  12  (moving  toward  a point  relative  to  a friendly  or 
enemy  FEBA).  Units  moving  to  a friendly  or  enemy  FEBA  have  a destination 
operational  group  (op  group)  number  (MVDT1 ( IDUM) ) and  relative  desired 
deployment  distances  from  the  FEBA  (MVDT2( IDUM) , MVDT3(IDUM))  specified. 

If  the  destination  op  group  is  engaged  (MTCDOG(J)  < 5) , then  the  unit's 
destination  will  be  set  relative  to  the  appropriate  color  FEBA  (blue  FEBA 
location  I F EBAB ( K , J),  or  red  FEBA  location  IFEBAR(K,  J)).  Obviously,  if 
unit  IDUM  is  blue  and  moving  toward  a friendly  FEBA  ( MVTCD ( I DUM ) = 11 ) , the 
blue  FEBA  will  be  used,  if  a red  unit  is  moving  toward  the  enemy  FEBA 
(MVTCD( I DUM ) = 1 2 ) , the  blue  FEBA  will  be  used,  etc.  If  the  destination  op 
group  is  defunct,  but  was  involved  in  an  engagement  (MVDTAl(J)  not  equal  to 
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0),  then  the  appropriate  color  FEBA  will  still  be  used  to  set  the  unit's 
destination.  The  actual  calculation  is  done  by  subroutine  DESTIN,  which 
does  a standard  coordinate  rotation  and  translation  to  obtain  the  destina- 
tion X,  Y (see  Section  5.10  for  DESTIN  write-up). 

If  the  destination  op  group  is  not  engaged  and  not  defunct  (MTCD0G^J)>4 
and  IFMUN^O) , or  if  the  destination  op  group  is  defunct  ( I FMUN ( J ) =0 ) and 
was  never  engaged  (MVDTA1 ( J)=0) , then  the  X,  Y destination  is  calculated 
relative  to  the  op  group's  forwardmost  unit's  location  ( I XY ( IFMUN(J) , K)). 
Again,  subroutine  DESTIN  does  the  actual  location  calculation. 

Note  that  in  CATTS,  neither  movement  code  11  or  12  can  be  selected 
interactively  via  the  maneuver  control  menu  (see  User's  Manual , Sections 

5.5.2  and  5.9.1).  The  only  2 ways  that  these  2 movement  codes  could  be 
given  to  a unit  are  via  the  table  driven  command  and  control  or  the  data 
base  disk  file.  Currently,  neither  one  of  these  contain  data  which  would 
cause  any  unit  tc  have  a movement  code  of  11  or  12.  Thus,  this  subroutine 
does  not  get  called  very  often  in  CATTS. 

5.10.33.2  Assumptions  and  Data  Sources 

The  basic  assumption,  made  by  the  MAFIA  V programmers,  is  that  it 
woul  be  desirable  tc  be  able  to  order  a unit  to  move  to  a destination 
relative  to  a friendly  or  enemy  FEBA. 

5.10.33.3  Equations 
(None) 

5.10.34  Subroutine  USEFUEL 
5.10.34.1  Operation 

This  subroutine's  primary  use  is  to  compute  the  cumulative  expendi- 
ture of  fuel  (both  gasoline  ar.d  diesel)  by  all  the  vehicles  of  a unit 
during  an  on-road  displacement  of  1 KM  by  the  unit.  This  data  is  then 
subsequently  used,  in  another  subroutine  (MOVE),  to  determine  the  total 
expenditure  of  fuel  by  the  unit  by  considering  the  fuel  expenditure  per  KM 
and  the  distance  moved  (in  KM's)  by  the  unit  during  the  simulated  time- 
step.  In  addition,  the  subroutine  accounts  for  supplemental  fuel  expendi- 
tures for  service  requirements  and  for  resupply  requirements.  Finally, 
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the  subroutine  accounts  for  an  estimated  fuel  expenditure  for  the  unit's 
housekeeping  requirements  and  for  a wasteage  factor  for  units  that  are 
displacing  in  combat  operations. 

5.10.34.2  Assumptions  and  Data  Sources 

The  basic  data  pertaining  to  the  expenditure  of  both  diesel  and  gaso- 
line fuel  under  various  operating  conditions  used  to  develop  the  algorithms 
in  this  subroutine  were  obtained  from  FM1 01-10-1 , Staff  Officer's  Field 
Manual  . In  particular,  Chapter  5,  Section  II,  Class  I and  III  Supply  pro- 
vided the  basic  data  (See  page  5-15  of  FM  101-10-1,  dated  July  1971). 

This  data  source  provides  several  estimating  factors  that  are  used 
in  the  subroutines  to  determine  fuel  expenditures.  First,  for  service 
operations,  the  average  daily  expenditure  per  unit  is  assumed  to  be  equal 
to  that  amount  required  to  move  all  of  the  unit's  vehicles  a distance  of 
16  KM  over  a road  network.  Second,  for  resupply  operations,  the  average 
daily  expenditure  per  unit  is  assumed  to  be  equal  to  that  amount  required  to 
move  10  percent  of  the  unit's  vehicles  a distance  of  50  KM  over  a road  net- 
work. Third,  a daily  expenditure  housekeeping  factor  is  included  that 
amounts  to  50  percent  of  that  amount  required  to  move  all  of  the  unit's 
vehicles  a distance  of  1 KM.  Fourth,  a wasteage  factor  is  applied  that 
increases  all  fuel  expenditures  of  units  in  combat  displacements  by  10 
percent. 

5.10.34.3  Equations 
For  hal ted  uni ts 

GU  = 1 .5  * R/ 1 440 


where 

GU  = gas  used  by  a unit  in  in  gallons  for  1 minute 
R = daily  rate  in  gallons  of  gas  use  by  a unit 

'or  company  or  greater  size  units 

GU  = (16  * R + 50  *( .1  * R))/144u. 


where 


GU  and  R are  same  as  above 

DU  = (16  * DR  + 50  *(.l  * DR) )/1440. 
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where 

DU  = diesel  fuel  used  by  a unit  in  gallons  for  1 minute 
DR  = daily  rate  in  gallons  of  diesel  fuel  used  by  a unit 
The  formulas  were  derived  from  Army  FM  101-10-1. 

5.10.35  Subroutine  YLIN(XL,  X,  Y) 


5.10.35.1  Operation 

This  subroutine  performs  a linear  interpolation  on  a probability  curve 
defined  by  up  to  six  linear  line  segments.  L is  an  array  of  15  elements. 
The  first  element  contains  a value  corresponding  to  the  number  of  line  seg- 
ments contained  within  the  curve.  The  following  elements  contain  the  X and 
Y values  alternately  for  each  segment  of  the  probability  curve.  The  sub- 
routine finds  the  segment  whose  X range  contains  the  X passed  in  the  sub- 
routine call  and  calculates  Y for  the  segment  found.  If  X is  smaller  than 
any  line  segment,  it  is  set  to  zero;  if  it  is  larger,  it  is  set  to  1. 

5.10.35.2  Assumptions  and  Data  Sources 

It  is  assumed  that  the  curved  passed  for  interpolation  has  zero  value 
for  all  X less  than  the  first  segment's  X value  and  one  value  for  all  X 
greater  than  the  last  segment's  X value.  The  following  diagram  illustrates 
this  assumption: 
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5.10.35.3  Equations 

Y = Yi  + (Y1+1  - Yi)(X-Xi)/(X.+1  - Xi) 

where 


(Xi,  Yi)  are  the  first  coordinates  of  the  ith  segment 


